4

I have a BPL project (with some base stuff) and an EXE project which has in it's Search Path the location of the other project's output (BPL and DCP). When the EXE project is built with "Build With Runtime Packages", it builds fine. However, it requires me to deploy the EXE and the BPL. So far so good.

Since I'd rather deploy just the EXE (no matter it gets bigger), I'd guess that I'd just uncheck "Build With Runtime Packages" and that'd be it, but it's not the case. It won't build, and start complaining about the missing classes. The only way I can compile the EXE project is if I add the path to the actual BPL project's DCUs to the EXE project's Search Path. I can do that, but why am I forced to point to the DCUs? Can't Delphi just take them from the BPL? It's not just a matter of taste, if I go this way, and link to the DCU's, when it comes to DCUs belonging to forms, it will then ask me for the forms DFMs, forcing me to also include my sources folder to the EXE project's Search Path, and now it would seem as they are getting compiled, which is prohibitive. I can't recompile my BPL project codebase each time I want to compile my EXE project.

I hope I have made myself clear.

Any help on how to achieve what is asked in the title is appreciated.

Thank you.

drakorg
  • 404
  • 4
  • 14
  • Uncheck build with runtime packages and make all your source visible to the compiler. You already know how to do this. Where is the difficulty? – David Heffernan Aug 30 '16 at 07:18
  • @DavidHeffernan I didn't want the BPL project (it's sources) to also be built everytime the EXE project is built. When bulding with runtime packages that didn't happen. I also wanted to think of them as separate things, isolating them and treating the BPL as an external dependency. I could stand giving the location of the DCU's, it makes sense, but the sources? Hm. Now it would all seem to be mangled and part of the same thing. With this approach, every time I build the EXE, I can see how the forms in the BPL project are getting built, too. – drakorg Aug 30 '16 at 12:14
  • What's wrong with having everything built? Then you know you are up to date. If a file hasn't changed it won't get rebuilt. It's how I work. 800mloc and compilation is typically a matter of a second or two. – David Heffernan Aug 30 '16 at 12:17
  • That's a big assumption. The BPL project could be incredibly huge, or you could be dealing with more than one BPL project, they could be N BPL projects (4 in our case). And instead of one EXE project, they could be N EXE projects (12 in our case). The 2 seconds can easily become more. The scenario I presented with one BPL project and one EXE project was a just a simplification to go to the bone of my problem. The same happens with actual external dependencies, they also get built on every build of every EXE project with this approach, whenever they require RES or DFM's files present in source. – drakorg Aug 30 '16 at 12:32
  • The fact that files that haven't changed don't actually get rebuilt will probably be my life saver here. But the fact that they are scanned for modification still bugs me a little. But I'll have to settle with this I believe. – drakorg Aug 30 '16 at 12:36

3 Answers3

5

There are two ways to link external libraries: static and dynamic.

When you are using runtime packages, this is a dynamic linking. Actual implementation is in the BPL file (which is a simple dll actually), methods and classes are imported from it on the process start. This reduces exe size, but requires BPL file to be shipped (same as usual dll). DCU files are not needed, because everything is already compiled and linked, linker need only to create import section.

When runtime packages are disabled, linker has to take object files for all classes and methods and combine it into the one executable. It could not extract this data from the BPL, because its is already linked executable. It would have to unlink it first, separating different modules implementation, which is basically impossible. So you have to provide DCU files, containing compiled object code to link your program.

So answer for your question title is simple - no it is not possible.

Ari0nhh
  • 5,720
  • 3
  • 28
  • 33
3

No, you can't. If you want to use runtime packages you have to turn on the compiler option to build with runtime packages.

As to the second part of your question: Building with runtime packages uses the *.dcp files to compile (the .dfm streams are linked into packages' resources so the *.dfm files are not needed directly). Building without runtime packages needs the *.dcu and *.dfm files (and any other required files).

In either case, you need to have the required files in your library/search path to be able to compile/build.

Ondrej Kelle
  • 36,941
  • 2
  • 65
  • 128
  • I chose this answer over Ari0nhh's because of the explicit mention of the reason the path to the *.dfm files was required (fact that was bugging me), but both basically nailed it. Thanks to both. – drakorg Aug 30 '16 at 12:22
  • To build without runtime packages. These files are required: `*.dcu`, `*.dfm` and `*.res` too if the library has compiled resources – Chau Chee Yang Jul 19 '18 at 03:42
0

It is possible, but is very hard to implement. And you will need to create a third project for this purpose - a loader. You need to turn your original EXE project to a DLL built with runtime pckages. The loader can include your DLL project, rtl.bpl, vlc.bpl and your BPL project as resources inside loader executable. Loader will need to manually do all things that are done by LoadLibrary Windows API.

You can read more about how to load DLLs from memory and find some code samples to start with here.

Eugene Mala
  • 1,081
  • 12
  • 25