I am confused a bit with a new RAD Studio version! Where can I specify a folder to put my output DLL files?
It is under Project | Options | Delphi Compiler.
The option you are looking for is named Output Directory (by default .\$(Platform)\$(config)).
The documentation says:
Specifies where the compiler should put the executable file.
You need to be careful about the various different targets. It's easy to modify the options for the release build, go back to the IDE, compile a debug build, and then wonder why your setting has had no impact. If at all possible it is best to set the options at the highest level possible. In the screenshot above I illustrate the setting at the root level.
in Project Options Delphi Compiler
Related
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.
I want to create *.bpl file but I am failing to do so.
Specifically, I am trying to make JEDI plugins, but I have tried an empty pure Delphi package, too.
If I create a new package in Delphi XE3, I get an empty unit - if I "make" this project called "Package1.bpl", I get a .dcu file in "debug/win32/", but no .bpl file.
No error is reported by the compiler.
An empty JEDI plugin (bpl-style) only gives a .dcu, too, while an empty dll-style JEDI plugin gives a .cdu and a .dll file in "debug/win32/".
This is the first time I am trying to make a new package, so I am completely lost.
What am I missing?
Go to the Tools menu and navigate to Environment Options -> Delphi Options -> Library.
There you find the Package Output Directory and the DCP Output Directory. These directories are the default output directories for BPLs and DCPs, so the bpl will be created if your packages is compiled, but in a different directory from what you expect.
The JEDI plugins probably have their output directory configured otherwise in Project -> Options.
For those that don't want to travel into Delphi IDE/options etc, lately in Delphi XE it's something like this:
"C:\Users\Public\Documents\Embarcadero\Studio\17.0\Bpl;"
Your exact folder might be different based on 17.0
These folders also end up in the path environment variable of your system, bit dangerous and can lead to some mighty magic loading confusion ?!
"How's that BPL still loading after it was deleted from my local project folder ?" :)
Another solution is to add "." to your project settings without the "". Prevents you from having to modify your delphi environment options/settings, something you probably never want to do since JEDI and other projects may rely on these default settings to function properly. Only change it if you know what you are doing and how to correctly make JEDI and others work if it was changed, this may get tricky/hairy, probably requires search paths to be added.
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.
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 read in a blog about Version Insight (http://www.delphifeeds.com/go/s/77066) that (among others) JCL doesn't have its .dproj files under version control and i was wondering what the advantages of that would be.
Especially since me and my collegue developer often "bug" each other with checking in project files with our own favorite debug settings (he likes optimization on, I want it off). And because of the regular hick ups of Delphi 2007 that screw up the dproj file with all kinds of faulty dependencies. Does not versioning help in anyway with these things?
We are using Starteam as our VCS at the moment.
If you're using Delphi 2009 or later Option Sets are a perfect solution for this problem.
Option sets are basically collections of settings that would normally reside in the DPROJ (which you do version) but instead stored in a .OPTSET file (which you don't version).
Make your DPROJ contain the settings that are common to all developers, that nobody is allowed to change unless it's an agreed across the board change.
Next in the project manager (D2009 and above) on first the DEBUG configuration node and then the RELEASE configuration node, right click and select "New Option Set". Call this option set something like "Local Developer Debug Settings.optset" and "Local Developer Release Settings.optset".
Now commit only your DPROJ to version control as it now refers to these .OPTSET files. You must name your option sets exactly the same on each machine for this reason.
When you want to make a local change to your project configuration rather than editing the project configuration, right click on the Option Set in the project manager and select "Edit Option Set".
The IDE will apply the changed settings from the option sets without modifying the original DPROJ. Settings are applied hierarchicly with option sets being the last to be applied.
I store, in my .dproj files, settings that are used by msbuild for my build process. For example, conditional defines, compiler settings, etc. If you do the same then you need to version them.
If you are using a version of Delphi where the IDE breaks the .dproj file on a regular basis, then surely revision control will help you fight back.
I can't see any advantage in not versioning them.
If you choose not to version your DPROJ, when creating your release builds I recommend you use a separate build script of some sort that you do version e.g.
a batch file that calls the command line compiler and specifies the compiler options and paths required.
a Finalbuilder project (much easier than a batch file)
an msbuild script (never done this myself but I assume it would be possible).
One solution for this issue is to be more discerning about what parts of the DPROJ (and also DFM files) you allow to be checked in.
You don't mention what version control system you're using but TortoiseHg has a hunk selection feature as part of it's commit process which lets you select individual lines within a changed file to be committed and still leave other lines uncommitted.
I use this method to never check in junk changes from the DPROJ (such as changing the active config from RELEASE to DEBUG) and the DFMs (e.g. changes to ExplicitHeight and ExplicitWidth properties).
The only reason i can think of to NOT version control DPROJ files is if, like the JCL, you can regenerate them as part of your build process. The JCL is a class library (code-library) not an application, and it targets multiple versions of Delphi with differences in their .dproj files. In fact, versions of delphi prior to 2005 didn't use .dproj files at all.
Later version of Delphi XE4, 5, 6, and XE7 are very stable constructing the .dproj XML files. I have no complain using git to version .dproj and .groupproj files. Updates to these files using the IDE editor result to expected neat and clean changes only.