This is a follow up question. Is it possible to set the build configuration for a command line build in Codegear 2009?
For example:
msbuild /property:BuildConfiguration=Release workspaceX.groupproj
Yes. In fact you're very close with your example. Use /p:Configuration="Name":
msbuild YourProj.cbproj /p:Configuration="Release Build"
It is Configuration="Name" for a C++Builder project, and config="Name" for a Delphi project, which you'll need to be aware of if your project group mixes Delphi and C++Builder projects. (I don't know why this is, but there you go. You would not believe how long that took to figure out. Edit: according to a comment, 'config' works in 2009. I can only state that for certain it did not work for us in 2010.)
You can also use /t: to specify a target, such as cleaning, building or making your project; /verbosity to set an output level ('quiet' is the closest that mimics the old C++Builder 6 compiler output without writing a custom MSBuild logger); and other switches which you can see if you type msbuild /? at a command line. You can end up with something like this:
msbuild YourProj.cbproj /p:Configuration="Release Build" /t:Make /verbosity:quiet /nologo
You'll need to include a line like this in your build script for each project in your project group. As far as I'm aware, you can't build or make a project group itself as a whole from the command line.
Related
I have both C++ and Delphi tests in DunitX. I am trying to get it to Build in FinalBuilder. C++ tests builds fine, but Delphi tests has the error:
"Error creating cfg file: C:\Tests.cfg Error expanding variables in Library Path : [Expression Error]: Variable\Object "DUnitX" does not exist! [$(DUnitX.);$(BDSLIB)\Win32\rele]
The FinalBuilder does not have a DunitX action, but has Dunit and NUnit ones. For both C++ and Delphi ones the action is Build. Thoughts on FinalBuilder integration appreciated.
IDE: RAD Berlin 10.1
FinalBuilder: 8
Open the failing project and look into the project options
Delphi Compiler -> Search path for any Target might contain $(DUnitX.) <- notice the dot
Make sure to remove the dot and make sure that you have the DUnitX environment variable set - for additional information see this article: https://www.finalbuilder.com/resources/blogs/postid/702/dunitx-has-a-wizard
If you are using the DUnitX version that ships with Delphi you can just remove the $(DUnitX.) from the search path as the DUnitX sources should be in the BDSLib directory.
However keep in mind that when you create new DUnitX projects via the Wizard it adds that variable to the project (that is probably where it came from originally) which then might again fail when building with FinalBuilder. I don't know how it behaves without that wrong dot if the variable does not exist.
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.
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.