Has there been a change in the way runtime packages are specified ?
I’ve just upgraded to Build 8.0.0.2222 because of another problem and my specification of runtime packages is not working - I’m getting FATAL: E2202 Required package ‘vcl’ not found.
I have vcl in the field next to the check box.
Do I need to set up a path somewhere ?
Compiling Berlin 10.1.
Sue
Hi Sue King,
We are currently tracking an issue where the Build Delphi action is incorrectly building Delphi projects. We will advise when we have a fix, it should be very soon.
Hi Sue
I just did a test with 2222 on a machine that has berlin installed, and it was able to build a project that used runtime packages ok. That said, I’ve been chasing my tail all day with differences between delphi versions, fix one, break another, and it’s difficult to test every version (debugging is a problem on my windows 10 creators update machine!).
Please try this build : http://downloads.finalbuilder.com/downloads/finalbuilder/800/FB800_2227.exe
I have tested this on two machines with XE, XE7 * Berlin and all my test projects compiled ok! If that doesn’t work, we’ll need to see your dproj file at least to try and figure out what is happening. dproj files that have been upgraded over many delphi versions often give us grief as the IDE project upgrade is often flakey at best.
Hi Vincent,
2227 didn’t help.
Jason’s comment is interesting - I upgraded because a project wasn’t building all the units in the project.
Let me know what I can send/do to help sort this out.
Regards
Sue
I was able to get the runtime packages working again by adding the path to the Emb Delphi dcu’s to the Search path for the project.
C:\pf\emb\18.0\lib\win32\release (abbreviated).
Which means I am back at square one with a project that appears to not be building all the units. Is this the same as the issue Jason mentioned ?
Sue
Hi Sue
Not sure why this is needed, that path should be added to the library path automatically. Can you send your FinalBuilder project and the dproj file to support so I can take a look at it. That way I can be sure I’m testing with the same settings.
Hi Vincent,
I’ve created a small standalone FB project that shows the problem. If I use run time packages, the build fails. If I don’t use run time packages, the build succeeds.
Email sent.
Sue
Sue
Hi Sue
Just took a look at your project and there’s a simple solution to the problem. Your library path is missing the standard part of the library path, which for berlin is : $(BDSLIB)$(Platform)\release;$(BDSUSERDIR)\Imports;$(BDS)\Imports;$(BDSCOMMONDIR)\Dcp;$(BDS)\include;
Add the above to the start of your library path and it should build fine (and you can remove the C:\pf\emb\18.0\lib\win32\release from the search path).
That will solve the problem. Now for the reason this stopped working, we pass --no-config to the compiler, which tells the compiler not to use the dcc32.cfg file in the bin folder, we recently fixed a bug where this was not being recognised be the compiler, which caused the compiler to use dcc32.cfg in addition to the projectname.cfg file we generate. dcc32.cfg has the following :
-u"c:\program files (x86)\embarcadero\studio\18.0\lib\win32\release"
So the version before the bugfix worked, but by luck more than design. The reason for specifying --no-config (which the IDE/MSBuild task does too) is to allow us full control over the library path.
FWIW, on our projects for building our products, the library path only has the defaults, everything else is in the project search path. The library path was fine back in delphi 1 days, but in this day and age, where multiple projects might use different library versions, it’s a recipe for problems. Which libraries a project uses is information that should be stored with the project not the environment. I guess I should blog about this, as it’s common problem. The true test of a good configuration, is when you can move your project source to another drive or machine and still have it build.