I'm trying to build a simple release build batch for our app. I'd like to use environment variables inside the <AppName>.cfg file. However these seem not to get expanded. Neither
-U"$(DELPHIKOMP)\VclZip;..."
nor
-U"%DELPHIKOMP%\VclZip;..."
work. However
-U"C:\DelphiKomp\VclZip;..."
does. Any idea what I'm doing wrong?
Please note: We're using BDS2006, so MSBuild is no option for now.
Update: As gabr suggested I wrote a little tool that expands the environment variables in my cfg and calls dcc32 for me. Thanks to all for their answers!
DCC32 doesn't support expansion of environment variables.
I'm pretty sure there exists a utility on the Internet which expands all variables in the cfg file, calls dcc32.exe and restores original cfg file, but I can't locate it anymore.
You can write such program pretty easily by yourself, though.
Why not pass them as command line parameters to dcc32 - in that case the shell will expand them.
FWIW, using Delphi 2006 does not preclude MSBuild, or make, or another build tool; just shell out to dcc32 as necessary.
Related
As stated in my title, basically I'm struggling on how to go about to include required files for a Delphi program to compile. I'm experimenting with Jenkins and using the execute Windows batch command for building the Delphi program (Delphi 2006 is used). It would be nice if there is some sort of generic method to find/include the required files since including it manually defeats the point of automation. Does anyone have experience with this? Or maybe know a script or batch that can include the needed files?
Thanks in advance if anyone can help!
When you use dcc32.exe directly, be sure, that all required include paths are set correctly in dcc32.cfg (-I). See here.Another option would be to use msbuild to build your projects.
Is there a way to tell a Delphi project that builds a DLL to use as a host application an executable in the same directory as the output directory of the DLL being built?
something like this:
One thing is, I'm using option sets with Delphi XE2, so in the dproj for the DLL I'm building I don't even have a DCC_ExeOutput directory, not sure if that matters.
Allowing this would seriously decomplicate some issues we've ran into trying to migrate from VSS to SVN.
Also, what do you call the $(thing)'s?
The $(name) things are environment variables. I tried setting the host application to .\$(Platform)\$(Config)\Test.exe and received this error message:
Could not find program, '.\%Platform%\%Config%\Test.exe'.
Note how the $(...) was turned into environment variable syntax.
I also tried with $(systemdrive)\Test.exe and received this error message:
Could not find program, 'C:\Test.exe'.
So clearly environment variables will be substituted with their values, if they do exist. I think it is reasonable to conclude that the environment used to start a host application clearly does not define the special Delphi specific environment variables.
So I think the answer to your question is that you cannot use indirection like this for the host application setting.
On the other hand, environment variables are substituted so perhaps you could use that to make things easier. In other words you could define some environment variables of your own. I've no idea whether that may be of help to you since I don't know the precise details of your problem.
I have a pre build event set up to generate the version/build number to embed in my exe. The event consists of a call to a batch file that does the actual work (a parameter is passed to the batch file). The batch file works as it should on all of the computers I've tried it on, including the Windows XP computers. It also runs fine as a pre build event on the 3 computers here running windows 7. The pre build event fails, however, on Windows XP. Delphi returns an error code that I can't seem to find a reference to anywhere, "20018".
I've tried a number variations to the way I call the batch file without any luck. Does anyone have an idea what's happening?
The build event is as follows:
call "..\..\Build Tools\PreBuild.bat" "$(PROJECTDIR)"
UPDATE:
I've removed the source of the batch file, since it had no relevance for the actual problem.
You gave so little information that I am tempted to vote to close. Instead I will venture a wild guess. You should post the commands in your post-build step.
If you don't know which line is failing, try the first one alone, and remove the rest, and see if that passes.
For example, I often have problems on XP machines using XCOPY commands in post-build steps, and these commands often result in really odd error codes that I am unable to diagnose or determine the meaning of. So if you have an XCOPY command, you should try the XCOPY inside and outside the build environment, and see if it works on that Windows XP box, for example.
You can copy the commands, as they are run, in their macros-expanded form, from the "Output" tab in the Rad Studio IDE, paste them into notepad, run them as a batch file, and try to figure out why they don't work on windows XP.
Here's an example of a workaround, using XCOPY. If this fails on XP, I tweak it till it works:
XCOPY SourceDir DestDir
I have had to fix it this way:
XCOPY.exe SourceDir DestDir
In another case, I found that I had to fix it this way:
call XCOPY SourceDir DestDir
You ALSO mention you are simply running a mysterious batch file and you fail to mention what it does. So let's see, what we could do differently to run a batch file from a post build step.... When I run a batch file like this, I sometimes have problems on XP, like this:
batchfilename.cmd
But when I run it differently, I find it worked on XP, but I lose the command line output:
call batchfilename.cmd
It seemed that something strange was happening when running post-build steps in the IDE, that could be resolved by trying the commands outside the IDE, in various forms.
The number (20018) you mention is a bit of a silly thing to go googling, it's probably the ERRORLEVEL (return value to the command shell) of whatever tool you are running in your batch file. Since you told us nothing about what tools you're running, I wonder if you have even done the basic step of looking at what happens when you run that batch file OUTSIDE the IDE on that XP machine. My guess is that if it didn't come from your own batch file, that it came from deep in the guts of MSBUILD itself, which is something that very few Delphi people will know the source code to (even the Delphi team itself is using a binary from Microsoft to provide MSBUild functionality). I notice that MSBUILD's built in tasks for doing post-build and pre-build steps are an area of the IDE that need improvement, especially when it comes to debugging problems like this. You can however, simply run them outside the IDE and see if they work that way, and you can try stuff, as I have suggested above.
If this is your batch file ... I suggest that due to dependency issues, you might not want to use such a batch file technique to modify an RC file, as it might expose some strange dependency issues in MSBUILD with RAD/Delphi build tasks. I have also seen some weird BRCC32 failures, on XP that I have not been able to reproduce.
Ok, I finally found the answer here:
http://delphi.about.com/od/devutilities/a/pre_post_build.htm
The problem was spaces in the path to the batch file being called. Apparently this isn't a problem in Windows 7.
Removing the space in the build tools directory and changing the pre build event to the following fixed the problem:
call ..\..\BuildTools\PreBuild.bat "$(PROJECTDIR)"
Here's the important bit from the link:
Command Line: This is the trickiest of them all, but after you get one working, they’re all easy. The trick here is not to use quotes on the program’s name but instead use the windows SFN (Short File Name). The reason is that, should you need to use quotes to enclose the path of your file, the IDE gets confused with too many quotes. So, these are the wrong ways of adding that command line above:
C:\Program Files\SoftwarePassport\Armadillo.exe D:\Dev\My Prog\Prot.arm /P
"C:\Program Files\SoftwarePassport\Armadillo.exe" D:\Dev\My Prog\Prot.arm /P
C:\Program Files\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
"C:\Program Files\SoftwarePassport\Armadillo.exe" "D:\Dev\My Prog\Prot.arm" /P
This last one should work, if it were not for the IDE to be confused with it. So, what does work is either of these:
C:\Progra~1\Softwa~1\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
C:\Progra~1\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
I'm sure this has to do with programming/coding, in e-text editor, under edit>settings, there's a tab called "environment", when clicked on you see 2 columns, the left if titled KEY, and the right is titled VALUE. I Googled it and I think it might be the equivalent of textmate's Environment Variables, here's their wikipedia page that shows a screenshot. I just don't understand what 'Project Specific Environment Variables' are, and what you would use them for, an example? How would I use this?
I'm pretty sure this will be an acceptable question for stackoverflow, if not, then I apologize.
I just don't understand what 'Project Specific Environment Variables' are, and what you would use them for
Most command line compiler tools uses environment varibales to control the compile and build process.
For example INCLUDE, LIB and LIBPATH are typical environment variables used by Windows based C/C++ command line compilers.
[give] an example?
Take for example the Microsoft C/C++ compiler. To run this compiler from the command line you need to setup a larger number of environment variables.
Infact this enter code herecompile needs so many environment variables, Microsoft even provides the vsvars32.bat file which does nothing more than correctly setup the environment variables.
I'm producing builds using MSBuild, and build configurations set up in the dproj on the command line. It's slightly disconcerting that the size of the executables thus produced are different (not by much, but still!) to what an IDE build produces. Any ideas why? I would have thought the same compiler is used?
The main power of building from the Delphi command-line compiler is standardization - you explicitly identify the options (on the command line, in the .cfg files, etc), and the compiler follows the options provided exclusively. In contrast, the IDE has many other behaviors that are not clear and explicit - for example, it may search library paths not specified in the Project Options. My guess is that something's happening in the IDE build of which you're not entirely aware - and this is why standardized builds are done from the command line.
To see what IDE is doind, check
Tools | Options | Environment Options | Compiling and Running | Show Command Line
And you can check the compiler messages.
The first answer on using the command line for build consistency is right on and it is probably something you needn't worry about if you are relying on a build system where production files are always sourced from the console builds.
On the other hand, if you really do want to figure out what is going on you should turn on map files (at the full detail level) and compare/diff them. If there are differences between the two they will show up there. Any other differences that may exist are likely a result of a commmand line option being different (such as a conditional flag that may be set in the IDE settings).
This behavior has existed in every version of Delphi I've used. (5 - 2006). I wouldn't worry to much about it. When I first discovered it I spent a lot of time trying to resolve the difference. Did I miss a compiler flag? Is there a discrepancy between the IDE and the command line compiler's supported options?
In the end I decided it wasn't that big of an issue. Both consistently produced functionally equivalent executables.
If you supply exactly the same params to the command line compiler the produced executables will virtually be identical.
In fact the IDE just calls the commandline compiler. Compile your project in the IDE and look at the messages window. you will see the full dcc32.exe call ...