I'm currently trying to set up a build process on a build server and I'm having some trouble installing JEDI with MSBuild. I'm using the Delphi XE2 compiler and based on this Stackoverflow thread I have created the following batch file that I use.
#echo off
:::
:::Build Delphi Project with MSBuild
:::
echo.
echo Setting up Delphi XE2 environment
echo.
SET BDS=C:\DelphiXE2
SET BDSBIN=%BDS%\bin
SET BDSLIB=%BDS%\lib
SET BDSTMP=%BDS%\temp
SET BDSAPPDATA=%APPDATA%\Embarcadero\BDS\9.0
IF NOT EXIST "%BDSAPPDATA%" MKDIR "%BDSAPPDATA%"
COPY /Y /B /V "%BDSTMP%\EnvOptions.proj" "%BDSAPPDATA%\EnvOptions.proj"
echo.
echo Build Delphi Project with MSBuild from Visual Studio 2017
echo.
SET MSBUILD_EXE=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe
"%MSBUILD_EXE%" %1 /t:%~2 /p:Config=%~3;Platform=%~4
I then call
compile.bat ".\Jedi\JCL\packages\JclPackagesD160.groupproj" "Clean;Build"
which works fine (atleast without any errors) and after that
compile.bat ".\Jedi\JVCL\packages\D16 Packages.groupproj" "Clean;Build"
But the second call fails because jedi/jedi.inc can not be found. What am I doing wrong?
Check the .dproj file(s). Is the subdirectory containing the jedi.inc file included in the search path? Is the file actually there? (It used to be in its own svn repository on sourceforge and included as an svn:external. No idea how they have solved this with git nowadays.)
Related
I am trying to build a delphi project in TeamCity, but I can't get it to work.
I'm using MSBuild to build the project and also have added BDS parameter to the build but I keep getting the error: MSB4040 There is no target in the project.
There are several things you need to be aware of. Firstly, the various environment variables and paths that Delphi requires need to be setup. Much of this is accomplished by the rsvars.bat batch file, but you can set up your own. Secondly, your EnvOptions.proj file needs to be set correctly to match the environment on your build machine. This file resides in %APPDATA%\Embarcadero\xx,x\ where xx.x is your Delphi version.
The following commented CMD file is one that I use to build Delphi XE7 applications in a TFS environment and should work with TeamCity and other build tools :-
#echo off
:::
::: Example for Build Delphi Project with MSBuild
:::
echo.
echo using MSBuild from VStudio 2013
echo.
SET MSBUILD_EXE=C:\Program Files (x86)\MSBuild\12.0\bin\MSBuild.exe
echo.
echo A copy of a Delphi installation from a developers machine is ok. MSBuild calls dcc32/dcc64, not the IDE.
echo The build targets are included in "$(DelphiInstallDir)\bin\CodeGear.Delphi.Targets".
echo DefaultTarget is "Make"
echo.
echo.
echo Set Delphi XE7 Vars
echo.
SET BDS=C:\DelphiXE7
SET BDSBIN=%BDS%\bin
SET BDSLIB=%BDS%\lib
SET BDSTMP=%BDS%\Temp
echo.
echo On a local Delphi developer machine the actual used Delphi settings are located here:
echo "%APPDATA%\Embarcadero\BDS\15.0\EnvOptions.proj"
echo.
echo The directories and files included in "EnvOptions.proj" must exist on the build machine!!!
echo.
echo Copy the (maybe modified) Delphi settings on your build machine to %APPDATA%\Embarcadero\BDS\15.0
echo.
MKDIR "%APPDATA%\Embarcadero\BDS\15.0"
COPY /Y /B /V "%BDSTMP%\EnvOptions.proj" "%APPDATA%\Embarcadero\BDS\15.0\EnvOptions.proj"
echo.
echo Set the Delphi Project Vars
echo.
SET PROJECT_SRC=C:\MyProjectSource
SET PLATFORM=Win32
SET CONFIG=Debug
echo.
echo Build Delphi Project with MSBuild
echo.
echo + /p = Parameters for the Delphi Project Build
echo.
echo + /t = Targets to be executed, e.g. Clean and Build
echo.
"%MSBUILD_EXE%" "%PROJECT_SRC%\myProject\myProject1.dproj" /p:Config=%CONFIG%;Platform=%PLATFORM% /t:Clean;Build
IF NOT ERRORLEVEL 0 GOTO ERROR
GOTO END
:ERROR
echo.
echo There were errors!
echo.
pause
EXIT
:END
pause
You could correct setup teamcity to build using MSBuild using the follow steps:
First you should define the parameter on teamcity that declares the enviroment variables that is seted by rsvars.bat, to do that in your Project access the Parameters and create a new configuration, select the type enviroment variable, set the same names and values from the rsvars.bat file aka: BDS, BDSCOMMONDIR, et all.
After that in you msbuild step edit the target option to "build".
You can see that this information is documented here http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Building_a_Project_Using_an_MSBuild_Command
Here you can see my params configuration
And here is the MSBuild Project configuration
i am trying to execute devenv.exe through windows batch command plugin in Jenkins
but it keeps on executing and fails to launch the application.
Console Output :
**In progressConsole Output
Started by user anonymous
Building on master in workspace C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace
[workspace] $ cmd /c call C:\Windows\TEMP\hudson3900292017086958332.bat
C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace>set DEVPATH=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace>set PATH=D:\app\nazopay\product\11.2.0\dbhome_1\bin;D:\app\nazopay\product\11.2.0\client_1;C:\Program Files (x86)\Integrity\IntegrityClient10\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\cde\tools;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Java\jdk1.6.0_23\bin\;C:\Program Files (x86)\Google\Chrome\Application;C:\MingW;C:\PROGRA~2\INTEGR~1\Toolkit\mksnt;%JAVA_HOME%;,;C:\Program Files\Java\jdk1.6.0_23;,;C:\Program Files\Java\jdk1.6.0_23\bin;%CLASS_PATH%;,;C:\Program Files\Java\jdk1.6.0_23\lib;,;C:\Program Files\Java\jdk1.6.0_23\lib;;C:\Program Files (x86)\M**icrosoft Visual Studio 10.0\Common7\IDE
C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace>devenv.exe
You must execute devenv.com.
The devenv.exe always attempts to open GUI, even when commands are given, and it can't. The devenv.com has output directed to standard output and works fine from Jenkins.
You also must pass arguments.
Without arguments both devenv.com and devenv.exe just start the IDE GUI, which is not what you want. The correct command-line is
devenv.com projectname.sln /Build Release /Project projectname
First is path to the solution you want to build. Then the /Build flag is followed by configuration. If you have multiple platforms, you have to pass configuration and platform combination, e.g. Release|Win32. The /Project flag names project to build (including all dependencies). If omitted, it builds all projects selected for build in given configuration.
Why don't you use msbuild?
This would be a good starting point for your windows build script:
call "%VS100COMNTOOLS%\vsvars32.bat"
msbuild projectname.sln /target:Rebuild /l:FileLogger,Microsoft.Build.Engine;logfile=msbuild.log || goto error
goto end
:error
#echo ERROR: Build failed
exit/b 1
:end
exit/b 0
This way you can also capture the output log that you can parse with one of the jenkins plugins.
Ofcourse, adjust the VS100COMNTOOLS to your version of MSVS
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've configured the Jenkins MSTestRunner plugin to use the following path to the MSTest executable: 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\mstest.exe'. However, although this path is correct, the build fails as follows:
cmd.exe /C "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\mstest.exe" "/resultsfile:/resultsfile testresults" /testcontainer:Project.Tests/bin/Debug/Project.Tests.dll && exit %%ERRORLEVEL%%
'C:\Program' is not recognized as an internal or external command, operable program or batch file.
What's the issue here, I thought this would be the normal way of configuring the MSTestRunner plugin as mstest.exe is installed beneath Visual Studio, which is again typically installed under 'C:\Program Files (X86)'? How do I work around this?
Have received confirmation from the plugin author that MSTestRunner 0.2.0 doesn't handle spaces in MSTest paths. I worked around the issue by instead creating an "Execute Windows batch command" build step in Jenkins that invokes mstest.exe directly, where I've surrounded the mstest.exe path with double quotes:
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\MSTest.exe" /testcontainer:Project.Tests\bin\Debug\Project.Tests.dll /resultsfile:testresults.trx
Found that my issue was 2 fold.
File entries are from local workspace dir
You must configure mstest in global tools and then select that instance within the build step.
Delphi 2009 uses build configurations. When you create a new project you have two default build configurations "Debug" and "Release".
Now I asked myself how to automate builds using MSBuild (which is supported by Delphi since version 2007).
You can start the "msbuild" command in the "RAD Studio Command Prompt" in some Delphi project directory and it will build the default build configuration (the last activated build configuration inside the Delphi IDE).
Now, I want to specify a certain (non-default) build configuration by a command line parameter.
The Delphi help asserts that the parameter is [/p:configuration=<configuration name>], which is wrong (Delphi 2009, Help Update 1)!
What is the right way?
Now, if you want to change the build configuration you have to add the parameter
/p:config=<BUILD_CONFIG_NAME>
For example:
C:\Projects\TestDelphiApp001>msbuild /target:Build /p:config=Release
or
C:\Projects\TestDelphiApp001>msbuild /target:Build /p:config=Debug
Copied from original "question"; note community wiki.
I tried this with Delphi XE. It didn't work until I figured out I needed to set the environment variables referenced by the .dproj file:
SET BDS=C:\Program Files (x86)\Embarcadero\RAD Studio\8.0
SET BDSBIN=C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin
SET BDSAPPDATABASEDIR=BDS
msbuild myproject.dproj /target:Build /p:config=Release
I've had the same problem and found the solution:
Write /p:config instead of /p:configuration
Write "Release Build" or "Debug Build" (in double quotes) instead of Release or Debug
It did it for me.