IDE: Delphi 6 Professional.
We have big projects.
I cannot use Project Groups to build them all, because I got OM errors, and strange file errors when I did it.
My idea was that I will use DCC32.exe
Priorly I had a fight with the command line parameters (dcc32.cfg), but it I thought I solved it...
Today I tried to compile projects with it, but at first project I got errors.
chdir c:\d\anyproject
dcc32 -b any.dpr
The error reported me that it wasn't found a unit. I tried to compile in Delphi, and it was successful.
So I checked the problem. Why the previous project buildings were successful, and why this wasn't...?
Then I realized that this dpr is using references to a subdirectory, but not all files added to the project, more of them are linked by project's "search path".
But if it's true, then this meaning that DCC32 ISN'T USING THE PROJECT'S DOF/CFG FILES!
So the problem is that Delphi merges everything to provide the result.
It merges the global search paths, the project's compiler directives, the searching paths, so everything, and using the project's conditional directives too.
If I understand it well, the DCC32 don't use, only the dcc32.cfg, and I must merge everything for the compilation, what is an impossible job, because I need to write a parser what is interprets the project's parameters, and merges with globals.
Or I misunderstand something, and the problem is caused by other thing what I missed?
I waiting for your suggestions!
Thanks for all idea, link, info, etc.
dcc32 options from the following places:
A dcc32.cfg file. This can be either in the current directory, or the same directory as dcc32.exe.
The command line.
The source code.
I have order these in order of increasing precedence. So, an option specified in source code always overrides settings made a dcc32.cfg file, or on the command line.
dcc32.exe will choose whichever dcc32.cfg file it finds first. It looks in the current directory first.
What all this means is that you are responsible for getting the settings from the .dof file, and from the IDE into your command line compilation environment.
This is one of the many reasons why you should upgrade. Modern Delphi versions use msbuild for command line compilation and make it trivially easy to be sure that your command line builds are the same as IDE builds.
When you watch an msbuild in progress you will see that it results in a call to dcc32.exe with all options specified on the command line. Transforming the project settings into a call to dcc32.exe is what you are now faced with. In Delphi 6 you have to do that yourself. In modern Delphi, the tools are part of the product.
This might help:
http://delphi.wikia.com/wiki/Compile_from_Commandline
It describes how to do commanline compiles with Delphi versions from Delphi 1 to XE3 and also links to the tool dof2cfg which you might find helpful.
IIRC the command line compiler always uses a configuration file named dcc32.cfg found either in the current folder or where dcc32.exe resides. You may try to rename or copy your .cfg file to dcc32.cfg and see if that solves your problem.
Related
The editor automatically adds the System.Actions unit when one of my forms is saved.
It compiles without a problem in the IDE, but unfortunately the Command Line Compiler can not find the file and gives me the error:
Error: F1026 File not found: 'System.Actions.dcu'
What am I missing?
In what follows, I am assuming that you are using msbuild to compile your program.
The System.Actions unit was added in XE3 to support actions in both FMX and VCL frameworks. Prior to that release FMX had no actions. Some classes were moved around, out of VCL units and into the new System.Actions unit which can be used by both FMX and VCL code.
So, the compiler error that you see suggests to me that you are unintentionally compiling with a version that pre-dates this change. My guess is that your IDE is XE3 or later, but that your command line build is configured to use an earlier version of Delphi. Most likely through the PATH environment variable, and whatever Embarcadero entry happens to be first in that variable.
If my hunch is correct then you need to ensure that you compile with the desired version.
The way I organise machines that have multiple Delphi installations is as follows:
Remove all Embarcadero entries from your PATH environment variable.
Whenever you need to build at the command line, configure the environment, for instance by running the appropriate rsvars.bat script (found in the bin directory of your Delphi installation) before you call msbuild.
This way you cannot accidentally find the wrong version because you have to explicitly configure an environment.
On the other hand, perhaps you are calling dcc32 directly. Don't do that. You will have to supply all the options and paths that are already defined in your project file. Repeating that is just a way to create a maintenence headache and make it likely that your command line build won't match the IDE build.
Instead, use msbuild to build your program. That way you can use the settings defined in your project file.
Thanks Hefferman for your advice but we shall stick with dcc32. It's easier to customize. For example we didn't figure out how to use more than one 'define' parameter with msbuild. It's possible to use dcc32 with the -NS switch for dependent 'uses' and that is our solution. We also create some .dpr files with code and in that case we do not have a corresponding .dproj file.
I'm having a problem with my build machine since I have moved to Delphi 10 Seattle. The build machine is producing different results to the IDE despite using MSBuild on the build machine and setting the correct configuration. It does the same thing on my machine, so it's not related to something on the machine. The differences I can see so far are:
Executable size is different. 39MB command line MSBuild, 35MB IDE build.
I get an integer overflow error in the executable produced from the command line whereas this doesn't happen from the executable in the IDE. They are clearly two different executables.
A COM DLL when built in the IDE is 22mb whereas it is around 59mb when built on the command line. A little further investigation shows that it is actually adding debug information into the DLL DESPITE debug information being off in the release configuration. If I set the "put debug info in a separate TDS file, I then get the same 22mb file plus a 36mb TDS file. This proves 2 things. debug information is being added, and I have the correct configuration as this change has an effect.
rsvars & MSBUILD /target:build /p:config=Release /p:platform=win32 project.dproj
The question marked as duplicate doesn't really answer the question, it only gives a hint as to what to look at.
The problem was a corrupted DProj file. How it was corrupted is difficult to say. However it was clear several command line options were being set that were NOT in the configuration. They also seemed to be missing from the DCC32 command line MSBuild spits out, but I'm beginning to wonder if I didn't just miss them. This project was originally probably at least Delphi 6, so has been continually upgraded. To fix it, I deleted all DPROJ, BDSPROJ and CFG files, leaving only the dpr file. I then opened up the dpr file in Delphi 10 Seattle which created the new dproj file. I reset conditional defines, search paths and compiler and linker options I wanted and viola, everything is back to normal.
I'm using the line below to have MSBuild build a Delphi 2010 groupproj:
MSBuild C:\src\myprojgroup.groupproj /target:Build /p:config=Release
I can't figure out how to modify the line above so that I can pass this argument
-EC:\mypath
to the compiler (bcc32.exe).
I've spent a fair amount of time trying to find this on the web. /property:name=value seemed likely to be what I need, but hasn't thus far.
Is this even possible, or do I have to learn about MSBUILD configuration files now...
Tom --
Probably the easiest way to do this would be to open the project in the IDE, set the settings in the IDE that you want, and then save.
Even better would be to set up a specific build configuration for these settings, and use that.
The IDE uses MSBuild itself, so any settings that you make in the IDE are saved in the *.DPROJ file (or GROUPPROJ, in your case), and so when you execute the command line, the exact same settings are used as were set in the IDE. If you use a specific build configuration for this specific set of options, you can simply call that configuration on the command line and you'll get what you want.
In other, shorter words: Let the IDE do the work for you.
Change your build configuration within Delphi, or manually yourself in the .DPROJ file. If you change the Release config itself in either of those places, you'll be fine.
Alternately, look at the .dproj file and see what the setting you want is called (eg., "IncludePath" or "OutputDir"). You can then use msbuild's /property switch. For example:
msbuild /property:WarningLevel-2;OutputDir=bin\Debug myproj.dproj
You can see these command-line switches and examples using the following from a command window prompt:
msbuild /? | more
A quick check of a .dproj file from D2007 indicates you're probably looking for either the DCC_IncludePath or DCC_UnitSearchPath properties.
Iam using Delphi 2005 and i have included a unit to the main unit using compiler directive i.e.{$I sample.pas} whenever I try to build the main pas file I get the below error . F 1026 File not found and it shows the path where the sample.pas file is available. I tried different options like tried adding the path of the pas file in the project options- search path and also in the tools-options -library path and it doesnt work. I googled it and found a solution which says to do the following:
In the IDE from the main menu, navigate to
“Tools|Options|Environment Options|Compiling and Running”
switch “Show Commandline” ON
AND set sure you have “Verbosity” set to “Diagnostic”.
The problem is Iam using Delphi 2005 and unable to find the “Verbosity” option in Delphi 2005. It would be great if some one can help me
In Delphi 2009 it is right under the Show Commandline setting:
However, unfortunately for you the verbosity option isn't present in D2006, so I guess it was introduced in either 2007 or 2009.
Oh, and as far as the include directive goes: if your sample pas isn't in the same folder as the unit in which it is included, you could try adding the path to the $I directive:
{$I ..\..\General\sample.pas}
Put the file in the same folder as your project units, and change its extension to ".inc" ( not mandatory but I think that by convention directives files are named like this).
A possible solution could be to get the code working in a package and then have the package keep that part of things compiled. I have been able to use include files in other paths with packages, but it is quite tempermental. It can start rejecting them even with packages for reasons I don't know. This is indeed a VERY annoying problem.
You might also look into doing your builds via your own batch files where you can take full control of the command-line settings that are being used.
I'm using the command line compiler for builds. One problem I see is that the paths mentioned there seem to need to be the short versions of the filenames such that they don't contain any spaces. I don't know so much about this even though I have used it for some time.
I recently upgraded to d2009 and the problem started then.
Is there a way around shortening the path?
I should say I'm not eager to change to use the MS Build tool at this time. I just want to build an old copy of my app & get back to other work.
Here's the path used in the dcc32.cfg file for the -I, -U, -O, and -R parameters:
$(BDS)\LIB;$(BDS)\Imports;$(BDS)\Lib\Indy10;C:\PROGRA~1\Borland\BDS\4.0\RAVERE~1\Lib;c:\prj\lib\lib2002;C:\DOCUME~1\ALLUSE~1\DOCUME~1\RADSTU~1\5.0\Bpl;c:\DOCUME~1\mike\MYDOCU~1\BORLAN~1\bpl;C:\Prj\Lib\LOCKBO~1\source;C:\Prj\Lib\MyComp;C:\Prj\Lib\ABBREV~1\source;C:\Prj\Lib\ZLib;C:\Prj\Lib\MinMod;C:\Prj\Lib\HELPMA~1;C:\Prj\Lib\DXGETT~1;c:\windows\system32;c:\prj\lib\xpburn;C:\Prj\Lib\WININE~1;C:\Prj\Lib\regexpr\Source;C:\Prj\Lib\VCARDR~1;C:\PROGRA~1\Raize\RC4\Lib\BDS2006;C:\Prj\Lib\jcl\lib\d10;C:\Prj\Lib\jcl\source;C:\Prj\Lib\jvcl\lib\D10;C:\Prj\Lib\jvcl\common;C:\Prj\Lib\jvcl\RESOUR~1;C:\Prj\Lib\ProE6\Delphi;C:\Prj\Lib\FastMM4;C:\Prj\Lib\OPENOF~1;C:\Prj\Lib\DEVELO~1\Library\Delphi11;C:\Prj\Lib\DEVELO~1\EX38D9~1\Sources;C:\Prj\Lib\DEVELO~1\EXBD88~1\Sources;C:\Prj\Lib\DEVELO~1\XPTHEM~1\Sources;C:\Prj\Lib\DEVELO~1\EX2EBC~1\Sources;C:\Prj\Lib\DEVELO~1\EXC5FB~1\Sources;C:\Prj\Lib\DEVELO~1\EX7C7C~1\Sources;C:\Prj\Lib\DEVELO~1\EXPRES~3\Sources;C:\Prj\Lib\DEVELO~1\EXPRES~4\Sources;C:\Prj\Lib\DEVELO~1\EXC73B~1\Sources;C:\Prj\Lib\DEVELO~1\EX7165~1\Sources;C:\Prj\Lib\DEVELO~1\EXPRES~2\Sources;C:\Prj\Lib\DEVELO~1\EXPRES~1\Sources;C:\Prj\Lib\DEVELO~1\EX749C~1\Sources;C:\Prj\Lib\DEVELO~1\EX0A1A~1\Sources;C:\Prj\Lib\Mad\madBasic\BDS4;C:\Prj\Lib\Mad\MADDIS~1\BDS4;C:\Prj\Lib\Mad\MADEXC~1\BDS4;C:\Prj\Lib\Mad\MADKER~1\BDS4;C:\Prj\Lib\Mad\MADSEC~1\BDS4;C:\Prj\Lib\Mad\madShell\BDS4;C:\Prj\Lib\Mad\madShell\DeXter;C:\Prj\Lib\Mad\madExcept\..\Plugins;
I've copied it from the IDE's path like I have done in the path and used a program to shorten the path names.
Although there are no spaces in that path, it still can't find indy's IdCoder.dcu at C:\Program Files\CodeGear\RAD Studio\5.0\lib\Indy10
According to the d2007 environment variables, $(BDS) would apparently expand to c:\program files\codegear\rad studio\5.0
The IDE is considering this library path to be valid.
Why is this happening? I bet it's a simple mistake I haven't thought of!
Thank you for your help!
You could try to put the paths in quotes, that's the standard way of handling path-/filenames with spaces in Windows, though I never tried that in Delphi DCUs.
So, instead of
$(BDS)\Lib\Indy10
try
"$(BDS)\Lib\Indy10"
You could also try
"C:\Program Files\CodeGear\RAD Studio\5.0\lib\Indy10"
to check if the environment variable is correct.
Although .cfg files do still work in the Delphi 2007 command line compiler, you should really be using MSBuild to compile your projects. CFG files are not used by the IDE anymore. Any compiler options you set design time do not get written to the .cfg file. Using MSBuild is not harder then using .cfg. And if you want it is even more flexible since you can change the actual build processes.
msbuild YourProject.dproj
Delphi actually will give you the command line needed in the output tab when you do a compile or build.
Build your project normally in Delphi.
At the bottom there will be a tab called "Output", Look for a line that says "Target CoreCompile" (in D2007 - may be different in other versions). The line below that will be the command line used to build your project (This is what you want). Btw - you do not have to wait for your project to complete building, you can hit cancel before it finishes because all you need is that DCC32 command line call. Also, if you had done previous compiles you may want to right click and clear the output before building so you do not have a lot of "noise".
Click on that line to highlight it, then right click the line and choose copy.
Open an empty batch file and paste. (warning,the line may be very long)
Now, go to the start of that line and if your path to the DCC32 compiler includes a space, then you will need to put quotes around the DCC32 call, don't put the quotes around the parameters.
Insert a line above the DCC32 call and enter dos commands to set the directory to the directory where your dpr file is, otherwise DCC32 will say it cannot find your project. For example.
G:
then
cd \Apps\MyProject
Save the batch file and you are ready to go.
Is the $(BDS) environment variable set when you're compiling the program from the command-line? If not, that might be the problem.
Putting quotes around paths containing spaces will likely solve the problem with spaces. This has worked for me:
-U"C:\Path to libraries\First library;C:\Path to libraries\Second library;C:\Path to libraries\Third library"
Check if you have applicationname.cfg file in the current folder. Dcc32 will try to read configuration from that file first. Only if the file does not exist will it read from dcc32.cfg.