I have a client application and a test application. If someone adds/removes units to the client application, I would like the same changes to happen to the test application.
I can think of 3 ways to do it, but all have drawbacks
1. Manually update the Test project uses list in the dpr.
The problem here is obvious, requires manual intervention per project.
2. Use a shared .inc file that contains the list of used units (list of frmXXX in '\forms\frmXXX.pas'...)
IDE doesn't like .inc files in the project file and would again require manual work to maintain
3. Same as #2, but use a shared unit instead of .inc file. So instead of updating the .inc you update the shared .pas
IDE would not really consider the files used by a shared unit as files in the project and they wouldn't get listed in View Unit dialog
Are there any other ways to keep uses lists of multiple projects in sync that I'm missing ?
Currently using D2007 but hopefully that doesn't matter.
You could use a build tool like Apache Ant, maintain the unit names in the script file (or a configuration file), and let Ant replace a placeholder in all *.dpr files using the replace task.
This would regenerate the dpr file automatically and keep them in sync.
Related
I have downloaded a component that has many packages in it, then I have install all the design time packages and generated all the other dcu files.I have to assign its path in Delphi search path every time I create a new application. Is there a way to assign its path to Delphi compiler search path once and all application will get access to these unit, so that I need not to manually set every time the path for a new application.
If you want to have some component automatically available for every new projects you need to change the default Delphi IDE options - specifically path locations - so that Delphi IDE knows where to find needed files.
You do this by going into menu Tools -> Options. Then in the TreeView which is used for splitting the options into multiple categories you select Enviroment Options -> Delphi options -> Library.
On the right side of the window you will now have different options regarding the path locations for libraries and source files.
In order to allow Delphi to find needed precompiled units of your component you need to add the folder in which they are located to Library path.
In order to allow Delphi to find source files of your component you need to add the folder in which they are located to Browsing path.
You can read more information about these settings in the Delphi documentation which is also available online here:
http://docwiki.embarcadero.com/RADStudio/XE6/en/Library
Note if you don't own Delphi XE6 but one of the previous XE versions simply change the webpage URL by replacing "XE6" with the one you own.
EDIT: I have edited my answer to provide more specific information. Old post below:
If you got to Tools -> Options (or is it Enviroment Options in latest versions) you can set Default options for the Delphi IDE. These options also include the Default path settings which will be automatically used in all new projects.
The way I do this is to have a folder "Lib2" which I use as the unit output directory whenever I compile/install components - I let the components (I mean their source files, etc) be installed whereever they want).
(I call it "Lib2" because traditionally Delphi has placed its own DCUs in a folder called "Lib", and putting all the third-party ones in a folder separate from that one avoided having to re-install Delphi if my set-up got into a mess.)
If you do that, all you need do for new projects is to include the path to that folder in the project search path and set that as the default search path.
The way to do that varies with Delphi version - the D7 era it was just a question of ticking the "Default" checkbox on the Directories/Conditionals tab of Project | Options. The only minor problem is that sometimes the component needs a resource file; if the compiler complains about that, just copy it to there manually.
In XE4, there are several ways of getting Delphi to find compiled DCUs that you've send to Lib2 or whatever you care to call it:
The simplest seems to to do what the other answer suggests, namely add the Lib2 path to the list of Library paths under Tools | Options. The compiler will then use the DCUs it finds there without needing to be able to finds their sources, which is generally a good thing (see "btw" section below).
A second way is to create a project "Option Set" (see the OLH for details of what they are and how to create one, and then edit it (again, see OLH) to include Lib2 in the list of search paths. After that, you can apply that Option Set to any project which it suits. There may be a way to automatically apply your Option Set to new projects, but I haven't managed to find it yet. In any case ...
A third way is to add a project which has Lib2 amongst its search paths to the Delphi repository and then create new projects that you want to use Lib2's contents from this entry in the repository.
Btw, there is an important practical point to having 3rd party libraries and any of your own standard ones output their DCUs to your Lib2 or equivalent. Because the compiler can find the compiled DCUs there, it does not have to be able to find the source code of those libraries in order to be able to compile your project. Isolating the compiled DCUs in this way helps avoid the dreaded "unit x was compiled with a different version of y" error message (y usually being a bpl) which has been the cause of so many cries for help in Delphi newsgroups over the years.
The company I work for develops a system in Delphi, that contains dozens of exe modules, and each of them is identical to a certain degree if it comes to source code. Sadly, nobody has ever cared about using libraries to put the shared code in. This means that each time there is a bug fix to do in the code all these modules share, a programmer has to make corrections in all of them separately! It always takes so much time...
I decided to find a method to put the shared code into libraries. I considered DLLs and BPLs. In this case BPLs seemed much more programmer-friendly and much less troublesome, especially that the code is used only in our software and only in Delphi.
I put all the code shared by all the exe modules into BPLs and everything seems fine, but there are certain things I don't understand and would be grateful if you explained them to me.
What I expected after dividing the code into BPLs was that it would be enough to deploy exe files with the BPLs I created. But it turned out that they need an rtl100.bpl and vcl100.bpl as well. Why is it so? I want to deploy exes and my BPLs only. I don't want to provide end users with a whole bunch of libraries supplied by Borland and third party companies :). I want them to be compiled within exes as they used to be compiled before. Is it possible to do that?
What I did so far was:
I put all shared pas units to BPLs. Each BPL contains units belonging to the same category so it is clear for programmers what code to expect in a given BPL.
Each BPL is a "runtime and designtime" library.
Each BPL is "rebuilt explicitly".
The two latter are default project settings for BPLs.
And if it comes to the exe projects:
I deleted all units that I had earlier put to BPLs.
I installed my BPLs from the Tools->Install package menu in BDS 2006.
In my exe project settings I checked the option "build with runtime packages" and I listed all my BPL packages in the edit box below (only my packages, as I cleared all other ones that appeared there).
This is all I did. The exe projects compile properly, but I have no access to the source code of BPLs (I can't navigate into that code from my exe projects), even though all BPLs are stored together with their source code files. Why? It seems strange to me.
I always tend to write lengthy descriptions - sorry for that :). I will appreciate your help. I just need a few words of explanation to the points I mentioned: deploying exe with my BPLs only, the correctness of what I did as a whole, and the inability to navigate into BPL source codes. Thank you very much in advance!
Thank you all for the discussion. Some said the approach I chose was not a good idea. Our software consists of more than 100 modules (most of them being something like drivers for different devices). Most of them share the same code - in most cases classes. The problem is that those classes are not always put into separate, standalone pas units. I mean that the shared code is often put into units containing code specific to a module. This means that when you fix a bug in a shared class, it is not enough to copy the pas unit it is defined in into all software modules and recompile them. Unfortunately, you have to copy and paste the fixed pieces of code into each module, one by one, into a proper unit and class. This takes a lot of time and this is what I would like to eliminate, choosing a correct approach - please help me.
I thought that using BPLs would be a good solution, but it has some downsides, as some of you mentioned. The worst problem is that if each EXE needs several BPLs, our technical support people will have to know which EXE needs which BPLs and then provide end users with proper files. As long as we don't have a software updater, this will be a great deal for both our technicians and end user. They will certainly get lost and angry :-/.
Also compatibility issues may happen - if one BPL is shared by many EXEs, a modification of one BPL can bee good for one EXE and bad for some other ones - #Warren P.
What should I do then to make bug fixes quicker to make in so many projects? I think of one of the following approaches. If you have better ideas, please let me know.
Put shared code into separate and standalone pas units, so when there is a bug fix in one of them, it is enough to copy it to all projects (overwrite the old files) and recompile all of them.
This solution seems to be OK as far as a rearly modified code is concrened. But we also have pas units with general use functions and procedures, which often undrego modifications - we add new functions there whenever necessary, but in single projects. So imagine that you write a new function in one of the 100 modules and put it into its general use unit. After a month or two you modify a different module and you think you need the same function you wrote 2 months ago. You have to find the module (it's difficult if you don't remember which one it was) and copy the function to your code. And obviously - the general use units become completely different in each module as long as they are stored in each project separately. And then, if there is a bug fix to do... the whole story repeats.
Create BPLs for all the shared code, but link them into EXEs, so that EXEs are standalone.
For me it seems the best solution now, but there are several cons. If I do a bug fix in a BPL, each programmer will have to update the BPLs on their computer. What if they forget? But still, I think it is a minor problem. If we take care of informing each other about changes, everything should be fine.
#CodeInChaos: I don't know if I understood you properly. Do you mean sharing pas files between projects? How to do that? We store source codes in SVN. This means that we would have to store shared code in a separate folder and make all projects search for that code there, right? And download from the SVN a project and all folders it is dependent on...
Please, help me choose a good solution. I just don't want the company to lose much more time and money than necessary on bugfixes just because of a stupid approach to software development.
Thank you very much.
Even though this question has an accepted answer I'm going to take a stab at it.
The title asks how to divide a project into bpls but the real question appears to be:
"What's the best way to share code between projects?"
There are a few ways to do this:
Shared units
Dlls
BPLs
Regardless of which direction you go you will likely need to restructure your projects. From your description it sounds like each project is developed in relative isolation. Code is shared using copy/paste, which quickly gets out of sync and result in a lot of duplicated effort. So lets examine each of the techniques for sharing code.
Shared units
This is the most straightforward approach. You create a shared location and place code you would like to reuse among your projects into this location. The units are statically linked into your projects so you don't need to worry about deploying extra dependencies along with the main executables. Statically linked units are by far the easiest to troubleshoot and debug.
The compiler needs to be able to find your shared units. There are 4 ways to tell the compiler where to look.
Add them to the project - SHIFT+F11 - Adds a reference to the unit into the project files (dpr, dproj). The IDE will normally use relative paths if the unit is located under the same directory tree as the project files, otherwise it will use absolute paths, which can be problematic if developer machines aren't configured identically.
The project's Search Path - CTRL+SHIFT+F11 Delphi Compiler > Search path - Add a directory and the compiler will look there to find units mentioned in the uses clause of any unit in the project. Its best to use relative paths if you can. You can also use environment variables: $(MyPath)
Global Search Path - Tools > Options > Environment Options > Delphi Options > Library - Win32 > Library Path - Any paths listed here are available to all projects on a machine. This is machine dependant
Command line - If you build from a script or build automation tool you can set the search path using the dcc32's -U switch or msbuild's /property:UnitSearchPath= switch.
Options 1 and 2 will be the most useful.
As far as your SVN repository goes you have a few options for organizing the projects and shared units. The simplest would be to place all projects under single trunk along with the shared units:
Projects
trunk
ProjectA
ProjectB
ProjectC
Library (shared units)
If for some reason the above structure isn't possible you could try this alternative:
ProjectA
trunk
Library (branch of main library)
ProjectB
trunk
Library (branch of main library)
ProjectC
trunk
Library (branch of main library)
Library
trunk (main library)
In this configuration changes made to each project's library folder would not be immediately available to the other projects. Each project would need to synchronize changes with the main Library project on a regular basis. A side effect of this is that changes that break other projects will be delayed until the other projects are synchronized. Whether you consider this a good or bad thing depends. On the one hand bugs are easier and cheaper to fix when the code they involve is still fresh in the developer's mind. On the other hand if you don't practice unit testing (which I highly recommend you do) or the code is very fragile or you just have developers prone to making reckless changes you may want to control how frequently those changes get pushed into other projects.
Dlls
Dlls allow you to share code by linking to it at runtime. They expose functions that can be called from a main executable or another dll.
While dlls are always linked at runtime you decide whether they are loaded at application startup or only when needed. Loading at startup is called static loading and in Delphi is accomplished using the external directive. The vast majority of the rtl/vcl classes that wrap system api calls use static loading. Dynamic loading lets to delay the loading of a dll until it is required. This uses the WinAPI functions LoadLibrary and GetProcAddress. A corresponding call to FreeLibrary will unload a dll.
Unfortunately standard dlls limit what kind of datatypes can be passed. If you need to access a dll from non-Delphi projects you will need to limit yourself to using c style data types. If you will only be using a dll with Delphi projects you can safely use Delphi strings and dynamic arrays as well if you use the SharedMem unit in the dll and any projects that use it.
You can safely use object's within the dll without problems but if you want to pass objects between the dll and the application you'll need to extract the object's data and pass it as primitive types and reassemble it into an object on the other end. This is called (de)serialization or marshalling and there are much easier ways to do this than rolling your own.
COM (Component Object Model) is well supported in Delphi but it has a bit of a learning curve. Consuming COM objects is pretty straightforward but designing one will take time if you're not familiar with COM. COM has the advantage that it is language neutral and is supported in the majority of languages targeting the Windows platform (including languages targeting the .NET framework).
Bpls
Bpls (also called simply "packages") are specially formatted dlls that make working with objects a lot easier. Like standard dlls they are linked at runtime and can be statically or dynamically loaded. They are easier to learn and use than COM dlls and provide more seamles integration into your projects than COM. Packages are composed of two parts: the bpl and the dcp. The dcp is like the dcu files generated when you compile a normal unit file except it contains a whole bunch of units in it. Using a class that is compiled in a bpl is as simple as adding the dcp to the project's package list then adding a unit to a uses clause of one of the project's units.
When you deploy the app you'll need to install the bpl as well. As other's have noted you have to include the rtl package at a minimum and most likely the vcl package if you use any forms. There is a way around deploying Borland supplied bpls with your projects. You can create a "mini" rtl package that contains only the units your project need. The difficultly is in determining which units to include.
Summary
From the description you've given creating a library of shared unit files to statically link against may be the most expedient route. I would also suggest trying out a program called Simian. It will help you track down duplicate code in your code base for inclusion in your shared library. It doesn't directly support pascal but it does a decent enough job using the plain text parser with a little tweaking of its configuration.
Also I can't stress enough the value of unit testing. Especially if you're moving toward shared libraries. A suite of well written unit tests run on a frequent basis will give you instant feedback when a developer changes a class and it breaks an unrelated project.
Imagine you have a project with an EXE and two different BPL modules, and somewhere in that codebase, there's a line that says if MyObject is TStringList then DoSomething;. The is operator works by examining the object's class metadata, stored in the VMT, and then following a chain of VMTs through the ClassParent pointer, to see if any of them match the class reference (also a VMT pointer) for TStringList. In order to make sure that this will work correctly, there needs to be one single VMT for TStringList that's the same throughout your entire program, no matter how many BPLs it's divided up into, which means it has to be in its own package. That's why system runtimes like rtl*.bpl and vcl*.bpl are necessary, and there's not much you can do about that. It's part of the price of using BPLs.
As for not being able to debug, you need to make sure that the BPLs are built with debug info enabled and that the debugger knows how to find the folder where the DCP (the file containing the debug info for the BPL) is located. And you won't be able to trace into system BPLs, because debug-enabled DCPs weren't shipped with your version. They were added pretty recently, I think in XE but it might have been in D2010.
Why can't I browse my source code? Is there a way to fix this?
You can not browse the source code of the units included in the packages because they are neither in your project, your library or search path.
The way I solve this is adding the directories to the project search path. This way the compiler does not know about those files (and does not try to recompile them) but the IDE let's you browse their content and debug into them.
"In my exe project settings I checked the option "build with runtime packages"
That is why you cannot deploy without the BPL's etc - this option is confusing for a lot of developers -"build with runtime packages" means that you will need the bpl's present at runtime. Uncheck that option and the packages will be linked into your exe at compileTime. (Your exe will g-r-o-w in size.) The idea behind the "build with runtime packages" is to keep the size of exe's down and allow several apps to share common bpl's because they are NOT linked into the exe # compileTime - that's the upside. The downside you are now experiencing - you must distribute your bpl's with your exe.
Is it possible to set the "Version Info" settings from code? I'd like to set the version numbering and the value for the "Comments" property without using the project options dialog.
Rather than editing the binary RES file that the IDE manages for you, you may find it easier to maintain a text RC file that contains the version-info resource. Write the resource-script file, and then include it in your project with a line like this:
{$R resources.res resources.rc}
You should remove the {$R *.RES} line from your project's DPR file, or else you'll get duplicate version resources. Do not use your project name as the name of your custom resource file; that name is reserved by the IDE.
The IDE-managed resource file also contains the project icon, so you'll need to include that in your resource script as well.
You can edit the resource script by hand, or you can write a program to edit it or regenerate it as one of your build steps.
Using a text resource script has the added side effect that it's easier to track changes to it in whatever source-control system you use, like CVS.
Solution would be to edit a project resource file. Check this c++ example http://www.codeproject.com/KB/cpp/UpdateVersion.aspx
I would recommend using a build tool, like FinalBuilder (which I use a lot), which can do this for you according to an appropriate scheme. Then you know that the build options are all as you wish, your numbers are incremented appropriately, and you can do things like upload to FTP site and lots more. In my scripts, the build number is included all the way through from EXE to installer and all.
You have to write wizard for that. Check out IOTAProjectOptions in D7IOTA.HLP file, source code of ToolsAPI unit and this thread
You'll need to overwrite the application resources.
Good starting point would be probably XN Resource Editor which comes with source code http://www.wilsonc.demon.co.uk/d10resourceeditor.htm
worth reading is also Inno Setup (which does set icon for executable output) - http://jrsoftware.org/isdl.php
I need to know if is there any option to compile a delphi project only if the source or any used unit, package etc has been changed.
If this is not possible, second alternative : Is there any option to generate exactly the same binary compiling two times the same project.
Thanks.
Edit: The usage is for a hash based WebUpdate.
A Delphi "compile" will compile only changed units. But as said, unit have data so the compiler can check which needs updating and which not. And the executable can change because the build process can rearrange the exe. Your web updates should not use a file hash, it should use version information to decide what to update and what not. That's the way installers check which files should be replaced.
Delphi compiles only changed units on a compile, and compiles all units regardless of change-status on a build.
Exe's are never the same, on a binary level. Just built a project twice, renamed the exe's to have a txt extension and compared them with Beyond Compare: it shows differences.
One (hard) solution: Make your exes using a Makefile! A makefile allows you to say "this exe is made from those files, using those commands". Make will only run "those commands" if at least one of the files you list as making up your exe is newer then your exe.
The hard part in this is setting up the list of files that make up your exe: You can easily get the list of files listed in the DPR/DPROJ, but you'll also need to identify all the linked resources ($R), all the included files ($INCLUDE), all the files that are implictelly compiled by Delphi because they're used in the "uses" clauses and are found on the Library Path.
Generating a Makefile for the general case is very difficult, but for one particular project it might work. For example you might consider your file dependent on only the files listed in the DPR files and then make sure you add all the relevant files to the DPR.
I want to apply a fix from QC to a Delphi 2009 unit (DBClient as it happens). I know I need to copy the unit to another directory and make the change to the copy. How do I then get Delphi to compile that unit and use it in favour of the DCU that already exists?
If you don't want to modify the original .Pas file, I do this by copy the .Pas file into my application folder, then choose built project, it will create new dcu file in my application folder, which will be used instead of the original one.
It's kind of a last resort (and not supported by CodeGear), but I do something similar to Mohammed when necessary. Except instead of putting any modified units into the application folder, I put them into their own folder with the rest of my library code and include this folder in my library path where it will be used by all of my projects. It also prevents me from having multiple (possibly slightly different) copies hanging around.
I also make a point of checking any updates to see what has changed so I can either remove the modified units or re-apply the changes to the newer (and presumably better) units from CodeGear.
I've never did this myself but there are projects in {RAD}\source\rtl along with batch build script. I believe this makes recompiling RTL functions easy. Other units should be recompiled easier.
If the changes you want to do are local and the units aren't widely used by other RTL/VCL units, the simplest way is to place copies of modified units separately from their standard place.
Another option is run-time patching aka detouring.