Currently I have not set any specific output directory for Delphi DCUs in my main project. This results in the DCU files ending up in the same directory as my .pas source files. To me, this feels ugly as I don't like the idea of mixing .pas and .dcu files in the same directory. What is the best practice for storing Delphi .dcu files - keep them all one directory for each project? Or maybe create one DCU directory for each source folder? Any ideas welcome.
The best way to do it is to create a DCU folder for each project, especially if you have more than one project that uses the same files. Otherwise, you can end up with different compiles with different compiler settings stomping each other's DCUs.
.dcu's are also dependant on defines, and e.g. debugging vs release configuration (*).
(*) While Delphi XE allows to put the "configuration" in the output path, IMHO that cure is worse than the problem
So I regularly recursively delete all .dcu's from the root of the dir where I do all my SVN checkouts.
The directory with components has a delphi version suffixed, and is outside the SVN checkout directory.
Agreed...mixing PAS and DCU files in the same directory is 'dirty'.
Whenever you start a new application, dll, or other Delphi project, one of the first things to do is to set the output directory. In later versions of Delphi this is done for you as the output directory is set as .\$(Config)\$(Platform) which correlates to the Debug or Release config option and Win32 platform. (Ending up with a default output directory of Debug\Win32)
If you build with custom compiler defines then it would be wise to have different project build options to include separate output directories for each set of custom compiler defines otherwise you have to do a full build to ensure that units are built correctly.
Related
[background]
I am creating common runtime package to use in my projects.
I don't like to make a mess in
C:\Users\Public\Documents\Embarcadero\Studio\*\Dcp
directory without a purpose.
I have to add directory with all of my *.DCU files to library path anyway.
So I was thinking about redirecting DCP files into same directory...
[question(s)]
Can I change default DCP output directory without worrying about side effects?
What is the purpose of placing DCP file in other place than DCUs?
What's the point of common DCP output directory? Does it offer any advantage I don't know?
I understand point of common package output directory - it's listed in system PATH variable.
The IDE uses DCP files for identifier resolution at design time. This applies equally to applications configured to use run time BPLs as well as the IDE itself (for extensions and components). If you are a component developer the BPL and DCP are technically the only files you need to ship. The DCUs as well as the source are optional, though most component developers do offer them for convenience and debugging purposes.
The IDE's extension APIs are a good example of this. There are classes that exist in the DCP and BPL files but don't exist in the source or dcus shipped with the IDE.
DCPs only need to be in the IDE's search path. They don't necessarily have to be in the public DCP folder. I believe the primary reason this folder is the default is for component developer's benefit. They need a convenient location to put DCP files and it needs to be somewhere with lax permissions so the compiler can write them and the IDE can load them.
In C++Builder XE5.
My understanding is that the binary file MyProject.res (which is created by the compiler in the same directory as the .cbproj file) contains compiled versions of the program icon and the project version details (although mine also seems to contain an XML manifest).
But this info is also contained in the .cbproj file and the .ico files; and if I delete the .res file then it seems to get recreated exactly was it was next time I open the project.
So is it safe to mark *.res as not being in source control? (I use git). And/Or is it possible to have it generated in the same directory as the object files instead, so it's not mixed in with the source?
(This certainly wasn't safe in C++Builder 5 - if you deleted the .res file then it complained it couldn't find it, and you lost your icons).
Update: Does this also apply to the .tlb file? This seems to be compiled based on the .ridl file, and if I delete it then it is automatically regenerated.
C++ Builder 6.0 and later will recreate RES files if deleted. I treat them as other temporary/build files (like OBJ files) and do not put them in version control software. I do have nightly backups that include all of these files though, which I think is still good practice.
I am not sure about TLB files. I would temporarily delete (aka-rename) one and see if it gets recreated to the same state. If so, should be same as RES files.
This does not hold true for 3rd party libraries though, if all you have is compiled resources. In that case, I still do not place in my version control though, since I am not going to be modifying them. I just have my backups.
For what it's worth, the TFS source control defaults are to exclude *.res but include *.tlb.
So you should expect *.res files to be created by their associated builds. If the build isn't going to be present, then the *.res file should be included.
I suspect that you're right about *.tlb files being built as well, but perhaps TFS doesn't exclude these on default because the extension isn't entirely unique to OLE type library files alone.
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.
How to set "Directories/Conditionals" in Project Options and "Library" path in Environment Options? Delphi help don't say much about these very important settings. I have all kind of strange errors because of wrong dependencies between my VCLs.
1.
I have merged a large set of 3rd party controls in a package called ThirdPartyPackages_D7.dpk. This is useful when I reinstall Delphi because I don't have to reinstall all those 3rd party VCLs amnually.
Then, I have my own controls in MyControls_D7.dpk which depends on the ThirdPartyPackages VCL. I also have another package BlgPackage.dpk that depends on MyControls.
At the end of the chain is my application (DPR project) which is using the controls in BlgPackage.
ThirdPartyPackages.dpk -> MyControls.dpk -> BlgPackage.dpk -> MyApplication.dpr
When I change/edit something to the second package (MyControls.dpk) and build the DPR application, it works. The compiler sees the changes made into that package.
However, if I close the project and load and compile the BlgPackage, it throws a nasty message that function xyz cannot be found in MyControls because I delete it (I have loaded MyControls' units into IDE in parallel with application's units). It seems that building the application only refreshes the DCU files for all used packages but not the DCP/BLP files.
How do I write and compile the code in the packages without explicitly loading the packages into the IDE and building them?
(Note: I have a nasty bug that does not allow me to switch between projects without restarting the IDE or to load a group of projects/packages (*.bpg) at the same time.)
2.
Another problem is that I want to store the compiled files (DCP/BPL/DCU) of a package in its folder (for example c:\MyProjects\Blg).
If I set the "Output directory", "Unit output directory" and "DCP output directory" boxes of BlgPackage package to its folder, not only its BPL/DCU/DCP files will be stored there but also the BPL/DCP files of MyControls will be stored there.
How can I have the binary files of each package in a separate folder?
Delphi 7, Win XP, all projects set to "Rebuild as needed"
You should explicitely compile packages - just compiling package files is not enough and as you have noticed leads to problems.
In modern Delphi versions you can create a project group (not sure about Delphi 7) that contains an application and packages you want to develop with the application, and you can easily switch between them and complile packages without need to close/reopen the application.
BlgPackage should not have an access to MyControls package sources (through "Library" path or by using the same directory), it should access only already compiled MyControls package, else the files from MyControls are compiled every time you build BlgPackage and the compiled files are stored in BlgControls DCU directory
ADDED
The "Library" path should lead to compiled files (.dcp, .dcu) and (if needed) resource files (.res, .dfm) only - it is enough to compile applications and packages that requires "MyControls" package. You can set the directory for compiled files directly in the package settings, and you should copy the resource files (if you need them) to the same directory manually. This directory should be included into "Library" path, or else you can use a directory already contained in "Library" path.
The "Library" path should not lead to source files (.pas) if you don't want these files to be compiled every time you build your BlgPackage or an application that requires "MyControls" package.
I use much simpler way for 3rd partie components and reinstalling Delphi.
Open regedit and find
[HKEY_LOCAL_MACHINE/SOFTWARE/Borland/Delphi/xxx] where xxx is version and export whole
branch.
Open file and delete keys LMKEY, LMLIC.
Copy C:\Program Files\Borland\Delphi x\Projects\Bpl folder to another location
Copy C:\Program Files\Borland\Delphi x\Imports to another location
Reinstall Delphi including any updates and GExpert
Import previously saved registries
Restore Bpl And Imports Folder
And whoala, Delphi is back with all 3rd partie components and IDE settings. Only limitation is that all components must reside in same folder before and after reinstalling Delphi.
This also restores TeamSource settings. If you are reinstalling Windows as well, be sure to make windows user with same user name as before.
MY solution (kinda dirty, but hey it works):
I put ALL 3rd party libraries.controls in a single package (a super-package). I put all my controls in a single package.
Now, when I migrate the packages to a different PC all I have to do is to copy/paste two folders and set two paths.
Works for me - others may not agree with it and I can't blame them. I blame the 'hell designers' from Borland/Embarcadero. If you look on StackOverflow you will see that until now nobody provided an elegant solution to this.
I would like to know, is there a way to automatically make the IDE/Compiler/other copy all the resource that needs to be linked with the DCU to the DCU output folder.
I often use forms that I pre-compile to avoid the needs to recompile the unit all the time in my main projects. The DCU gets updated, but we need to copy the DFM manually everytime it changes. Same goes for any {$R *.res} specified. Maybe we could maintain those file directly in the DCU folder... but doesn't quite make sense to have a .DFM in a different folder than a .PAS
I looked for a compiler switch that would do it... Unsuccesfully.
Anyone knows if/how it can be achieved?
I'm using Delphi 2010
You could create a simple Post Build event which performed the copying. That way whenever you did a build, the system would copy the necessary files for you. The build events are available from the Project Options menu, there is a Pre-build and a Post-Build script.
For *.res files you can specify output path in "Project Options | Resource Compiler | Directories and Conditionals | Output directory for .res files"
But for *.DFM files you have to use skamradt's suggestion (Post Build event).