Using windows 10, delphi 11.2, msbuild 4.8.4084.0. I have a set of scripts to rebuild all projects. Currently, it invokes msbuild like so:
msbuild /v:q /p:config=Release /p:platform=Win32 /t:rebuild someproject.dproj
And whether a map file is created seems to depend (as it should) on settings within the dproj file - more or less. (Delphi seems to treat mapfile=off as the default if its absent, whereas msbuild seems to treat "Detailed" as the default).
In an attempt to suppress the map file, I've tried using this msbuild command:
msbuild /v:q /p:config=Release /p:platform=Win32 /p:DCC_MapFile=0 /t:rebuild someproject.dproj
This results in a map file being generated that matches the detailed map file in size. The msbuild command does respond to the extra parameter sometimes though. e.g. DCC_MapFile=1 will generate a very small map file. But any other value (0, 2, 3) and you get the large map file.
Related
We use DELPHI 10.4 and MSBuild on a JENKINS slave for CI within our projects.
As the paths to *.exe output, search folder, .... in the given *.dproj on our local clients are different on the JENKINS slave we use *.optset files with paths adjusted to the Jenkins slave.
This strategy seems to work nicely except for some project where it seems that the compilation is only based on the *.dproj settings.
To ensure the use of an options file we add to the *.dproj the following statement
<Import Condition="Exists('$(OptSet)')" Project="$(OptSet)"/>
But this seems to fail sometimes.
Q: how to force the usage of the *.optset file, how to handle the compilation on different systems with MSBuild - some very flexible replacements for path settings.
We have Delphi 2010 setup as described here and jobs are running fine.
Now we need to add Delphi XE5 to that node as well.
Problem are variables BDS and BDSCOMMONDIR.
They are set as global variables pointing to e.g. BDS points to C:\Program Files (x86)\Embarcadero\RAD Studio\7.0.
For XE5, BDS should be have the value of C:\Program Files (x86)\Embarcadero\RAD Studio\12.0.
So how to setup multiple delphi versions?
I am using batch scripts for each build job.
Each script is able to set different environment variables. Basically I set the content of Delphi's rsvars.bat in my specific build scripts (Delphi paths, path to MSBuild depending on Delphi version etc.).
So the build script for a distinct build job contains the call to MSBuild (thus I have not set up MSBuild through Jenkins).
Could look something like this for you:
set BDS=C:\PathToDelphiLib
set FrameworkDir=C:\Windows\Microsoft.NET\Framework\v3.5
set FrameworkVersion=v3.5
set PATH=%FrameworkDir%;%BDS%\bin;%PATH%
set LANGDIR=EN
// set other variables
echo ### building the project
MSBuild.exe %WORKSPACE%\YourApp\YourApp.dproj "/p:Win32LibraryPath=$(BDS)\lib" /target:Build /p:config=%AConfigVariable% /p:Platform=Win32 /p:DCC_ExeOutput=%OutputDirVariable% /verbosity:quiet
In Jenkins then I can set up the Build using Windows Batch
call %WORKSPACE%\YourApp\ContinuousIntegration\DelphiXE2_Build_Release.bat
An advantage is that you can cascade batch scripts and keep all that logic away from Jenkins. I have also put my build scripts under version control. Everything is inside the repository and under control.
I have a project for which I need to build two executables: one under Delphi XE2 and one under XE3. I have a build script which builds each version (i.e. one script for XE2 and one for XE3).
If I run the build script for the last version of the IDE I ran, all works well (i.e. run Delphi XE2, build app, run XE2 build script).
However if I run the build script having just run a different version of the IDE I get an AV as soon as my app starts (I.e. run Delphi XE2, built app, run XE3 build script).
It looks as though something about the build script is being cached/modified by the IDE and I need to restore the appropriate data for the version I want to build with. I've tried this with the .dproj, but no luck.
Or could it be loading form resources - both editions show errors due to non-existent properties at start up if the IDE. If so, is there an easy way around this without having maintain multiple versions of all the .fmx files?
Here's a sample build script:
set path=%path%;c:\Windows\Microsoft.NET\Framework\v3.5
set path=%path%;c:\Program Files (x86)\Embarcadero\RAD Studio\10.0
set path=%path%;c:\Documents and Settings\All Users\Documents\RAD Studio\10.0
set BDS=c:\Program Files (x86)\Embarcadero\RAD Studio\10.0
set FrameworkDir=c:\Windows\Microsoft.NET\Framework\
set FrameworkVersion=v3.5
set failed=false
cd \myprogs\monkeystyler
msbuild monkeystyler.dproj /t:build /p:config=full||set failed=true
cd build
if not %failed%==true goto Done
echo ****FAILED TO BULD MONKEYSTYLER
****
Pause
exit
:done
Let's take a look at this line in your XE3 script:
set path=%path%;c:\Program Files (x86)\Embarcadero\RAD Studio\10.0
My guess is that you follow that up in the XE2 script with:
set path=%path%;c:\Program Files (x86)\Embarcadero\RAD Studio\9.0
At which point your path variable looks like this:
set path=%path%;c:\Program Files (x86)\Embarcadero\RAD Studio\10.0;c:\Program Files (x86)\Embarcadero\RAD Studio\9.0
And so the second script fails because the paths from the first script appear earlier.
The elegant way to fix this is to use setlocal and endlocal in your scripts to isolate them from each other.
setlocal
set path=%path%;c:\Windows\Microsoft.NET\Framework\v3.5
set path=%path%;c:\Program Files (x86)\Embarcadero\RAD Studio\10.0
.....
endlocal
The hacky way to fix it is to set the path like this:
set path=c:\Program Files (x86)\Embarcadero\RAD Studio\10.0;%path%
Please use the elegant approach!
What's more you should use pushd and popd to isolate directory changes to each script.
If this doesn't solve everything, do give more information. For a start, error messages are very useful.
The last IDE that you run will update the EnvOption.proj in your <user>\AppData\Roaming\Embarcadero\BDS\<version>folder.
This contains all your search paths, among other things.
This file is indirectly included in your project. So if you run say XE2's IDE then compile your XE3 app, you will get the wrong paths.
You will probably want to disable that and explicitly specify your search paths in each project's dproj file.
e.g. msbuild myproj.proj /p:ImportEnvOptions=false
This is my best guess. Sorry if it's 5 years too late. I have just struggled with similar issues!
All the best
Steve
I went back to my suspicion that it was the form file resources.
My theory was that the with the form files saved by the 'wrong' version of the IDE, when a project built with a different version tried to load them I was getting access violations due to the app trying to load data for properties which where not available in that edition.
To test this I got compiled the project successfully in one version of the IDE (XE3 in this case), did my automated build and tested that the app ran (it did).
I then loaded a .fmx file for the project and added a non-existent property to the form.
Build and the app fails same as before.
Remove the added property and build now succeeds.
All (!) I need to do now is write some code to parse the form files and remove any non-existent properties for the version I'm building.
I'd like to make builds from the command line and I'm wondering if there's a way how to execute the command line compiler with selected build configuration ?
I know there is option --no-config which won't load default dcc32.cfg file but I would like to set the build configuration I've prepared in my project.
I would like to run something like
dcc32.exe --some-option RELEASE Win32 PLATFORM
Is there some option for selecting build configuration ?
Thank you
You need to be using msbuild rather than dcc32 for this:
msbuild myproject.dproj /p:Config=RELEASE;Platform=Win32
Make sure you have called the rsvars.bat file from the RAD Studio bin folder before you attempt to call msbuild. This sets up the necessary environment variables.
The great thing about the modern msbuild based build system, as implemented in Delphi, is that you can quite easily ensure that your command line builds are identical to your IDE builds.
As far as I know, you can use the dcc64.exe to compile for 64-bit if you do not want to use MSBuild. It is in the same folder as the dcc32.exe (and dccosx.exe for compile for OSX)
this is a batch file that i have. It is located in C:\Work\6.70_Extensions\Lab Tools\ folder.
ANT.BAT:
set CLASSPATH=%CLASSPATH%;.;c:\JavaMail\javamail-1.3\mail.jar;c:\JavaMail\javamail-1.3\mailapi.jar;c:\JavaMail\javamail-1.3\pop3.jar;c:\JavaMail\javamail-1.3\smtp.jar;c:\JavaMail\jaf-1.0.2\activation.jar
CALL "C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat"
#echo on
%ANT_HOME%\bin\ant -logger org.apache.tools.ant.listener.MailLogger -q -buildfile "Master Build.xml"
pause
along with ant.bat, i have a Master Build.xml file located inside the same folder.
When i double click on ant.bat, it will execute the Master Build.xml ant script properly.
However, whenever i try to use another application to open the batch file's absolute path, it always state that Master Build.xml file does not exist!
I tried to open the absolute path using both console application and another ANT Script(via Cruisecontrol framework) but both gives the same error. What is the error here?
for your information here is what ive done with cruisecontrol:
create config.xml (to set intervals for builds)
create nightbuild.xml (so that config.xml will go into it to perform required tasks)
nightbuild.xml will run several console applications to sort files, checkout files from version control etc
lastly, nightbuild.xml will execute ant.bat file to execute the build
These files, config.xml and nightbuild.xml are found in C:\build
When you execute from a directory other than the one containing Master Build.xml, Ant will fail to find the build file, which it expects to be in the current working directory.
You could set an additional environment variable to specify the path to the build file, e.g.
%ANT_HOME%\bin\ant -buildfile "%MASTER_BUILD%\Master Build.xml"
If you set your variable to an absolute path (e.g. C:\Work\6.70_Extensions\Lab Tools) then it will always work. If you use a relative path (e.g. .\Lab Tools), then it will only work if executed from the relative root dir.
(BTW, life will probably be easier if you use buildfiles without spaces in their names, e.g. master_build.xml rather than Master Build.xml).