Best strategy to set up global Release/DebugDCU paths in the IDE, as example for Spring4D DCUs

[pyscripter 857]

3 minutes ago, GabrielMoraru said:

why would you need to redownload Delphi dependencies when you upgrade Delphi

You don't.  MultiIstaller can use existing library source code folders.  You only clone git repos once.  You then just pull the changes.

Edited October 7 by pyscripter

[GabrielMoraru 58]

17 minutes ago, pyscripter said:

You don't.  MultiIstaller can use existing library source code folders.  You only clone git repos once.  You then just pull the changes.

Ok. I guess, if you really want to keep the 3rd party libraries up to date, by the clock... 
Usually, I am happy with the stability of my 3rd party libraries... I only update them once per year 🙂
Some of them have my own bug fixes so I prefer to keep my current version 🙂

 

I general I rather write my own code than depending of 3rd party code. So, I don't have much of those.... which makes MultiIstaller of less use, for me 🙂

----------------

 

Anyway, I like your setup. I don't see any -r atrocity in there 🙂

Edited October 7 by GabrielMoraru

[GabrielMoraru 58]

Quote

pyscripter
>I know this will be frowned upon.  However, in my case it saves me time.   When a dependency gets updated, I just pull the latest updates from the git repo without having to install the components.  

 

So, from what you say, I guess those 3rd party libraries also don't use $Auto. Right?
It is so sad. The moment Embarcadero introduced the $Auto, it revolutionized packages. With it, you can have one single package (DPK file) for all Delphi versions (since Auto was introduced). A true game changer. 

 

Quote

pyscripter
>I know this will be frowned upon. 

No. Unless you have large amounts of code (could also be waived, if you don't mind waiting 1 extra minute to compile the 3rd party libs with code. Some have patience...🙂).

Edited October 7 by GabrielMoraru

[GabrielMoraru 58]

On 10/3/2025 at 12:15 PM, HaSo4 said:

Hello Delphi community,

I'm unsure about the setup for Delphi 13 Patch 1 library paths.
Usually I do this with the editor in Delphi under Tools/Options/Language/Delphi/Library/

You asked a simple question and we really deviated. I apologize. 
So, let's answer your answer concretely. If you don't want to be depended on your 3rd party library and make it work with all Delphi versions, you need to set these 3 simple things:

 

In your 3rd party package (Spring4D):

1. Let Delphi choose the correct output folder by using modern environment variables:

What it does:

This will put the DCUs in the:

• "Spring4D\22.0_Win32_Release" folder - for Delphi 11 
• "Spring4D\23.0_Win32_Release" folder - for Delphi 12
• "Spring4D\37.0_Win32_Release" folder - for Delphi 13.

 

2. Let Delphi choose the automatic BPL versioning using modern environment variables:

What it does:

This will make Delphi to output a BPL that has a suffix based on the Delphi version number.
This way you can have one unique BPL for each Delphi version.
Example: Spring4D_370.bpl (for Delphi 13), etc

 

3. Add your Spring4D path to the "Library Path" (not "Search Path"!):

c:\YourProjects\Spring4D\$(ProductVersion)_$(Platform)_Release <-- Add here your REAL path instead of "YourProjects"

What it does:

This lets the compiler find the precompiled DCUs. This way you won't have to compile Spring4D (which is not small at all) every time you compile your project. 

 

That's it. 

 

Advantages:

1. Maximum fast because your compiler will find the precompiled libraries.

2. Your projects (observer the s) will not care where Spring4D is installed. So, no need to mess up the "Search Path" of every project you have with hard-coded paths. You can easily move Spring4D folder without having to open all your projects and update the "Search paths" to reflect the new location of Spring4D.

3. When you install an new Delphi edition, all you have to do is to right click Spring4D and choose "build".

 

Edited October 7 by GabrielMoraru

[pyscripter 857]

51 minutes ago, GabrielMoraru said:

So, from what you say, I guess those 3rd party libraries also don't use $Auto. Right?

Not sure how you deduced this.  All of my component libraries and many of the third-party ones I use do have $Auto.  In fact I posted about it when it was first introduced with a bug which was later fixed.  And I agree it is very useful. 

 

51 minutes ago, GabrielMoraru said:

Unless you have large amounts of code (could also be waived, if you don't mind waiting 1 extra minute to compile the 3rd party libs with code

Again not sure why you say this.  You don't have to compile everything every time. Not even when you switch platforms if you set a platform specific DCU output directory. And in any case my 1m line project builds in about 20 seconds. 

Edited October 7 by pyscripter

[Wagner Landgraf 49]

7 hours ago, GabrielMoraru said:

No custom scripts ... no registry editing ... Just right click and "Build all".

Well, you need to add library path configuration to the new Delphi IDE. Unless you use migration tool to migrate library path settings from a previous to new Delphi version. That is registry editing, anyway.

Quote

 no -r hocus/pocus, no virtual machines

This has nothing to do with $(Auto). It's used to separate settings per "project", or per "environment". 

Quote

Honestly: Cannot be much simpler than that!

It's interesting how developers tend to reduce the truth to their own experience. It's like the old "Free vs FreeAndNil" discussion or "which language is best": usually a person with strong opinion ignores other users' experience or needs.

 

It's not that simple. As I said, building only generates the binaries (dcu's, dcp's and bpl's). But you still have to add the folders containin the dcus to the library path - if you use them globally.

 

You still have to handle the location of generated bpls and make sure Delphi can find them.

 

No custom scripts? You still have to build the projects for all the platforms you use. If you use all of them, good luck manually building from the IDE a gazillion of packages for a gazillion of platforms - it can be as many as 10 in Delphi 13. And good luck waiting for such building, one after one.

 

Want to have it really correct? You have to build the binaries for both Release and Debug configs, and add the proper folders to both Library Path and Debug Library Path, so when building your own application for Release it won't add debug info from 3rd party libraries, and when building your application for Debug you will be able to debug into the 3rd library code.

 

You want to ctrl+click an identifier from a 3rd party library and have the IDE Code Insight navigate to its source code? You have to add the folders of the source code to Browse Library Path so Code Insight and debugger can properly find the unit you need to open and show it to you.

 

You want to have them installed in both 32-bit and 64-bit IDE? You also have to rebuild the design-time packages for 64-bit platform and also install them in the 64-bit IDE.

 

The list goes on and on.

 

Quote

TMS and other proprietary mammoths like this need to be indeed re-downloaded

Wrong. Again a generalization. 

In either case, those are all reasons why we created Smart Setup and tried to make it as flexible and fast as possible.

 

[Wagner Landgraf 49]

7 hours ago, GabrielMoraru said:

I don't see any -r atrocity in there

Curious to hear why you consider -r an atrocity.

[GabrielMoraru 58]

5 hours ago, Wagner Landgraf said:

But you still have to add the folders containin the dcus to the library path 

Yes. I already clearly said you do have to do that. And that's good because with Library Paths your project does not care where your 3rd party libraries are. The second advantage is that you can link to the DCU files instead of PAS files - if it happens to work with large projects it matters. Your alternative "costs" the same amount of time because you will have to add the paths to the DPROJ files. But in this case, if you change any of your folders you will have to manually edit all your projects!
 

> You still have to handle the location of generated bpls and make sure Delphi can find them.
You are very wrong here. You don't.

 

> No custom scripts? You still have to build the projects for all the platforms you use. If you use all of them, good luck manually building from the IDE a gazillion of packages for a gazillion of platforms.

Have you ever heard of Build Groups? You will find it into the Project Manager. 

 

> You have to build the binaries for both Release and Debug configs, and add the proper folders to both Library Path and Debug Library Path, so when building your own application for Release it won't add debug info from 3rd party libraries, and when building your application for Debug you will be able to debug into the 3rd library code.

Please do read my previous posts. It even has screenshots.🙂
Embarcadero solved that with $(Config). So, one single path is enough (see my screenshots). Delphi will take care of the rest automagically. 

 

> You want to ctrl+click an identifier from a 3rd party library and have the IDE Code Insight navigate to its source code? You have to add the folders of the source code to Browse Library Path so Code Insight and debugger can properly find the unit you need to open and show it to you.

Of course. Your alternative would be to add the source code of ALL your 3rd party libraries to your project: same amount of work but sloppy (IF you work with large projects).

 

>Wrong. Again a generalization. 

No. It is not. It is backed up by facts. TMS is not using $auto. See: fact.
Actually TMS is one of the libraries that makes migration to a new edition of Delphi difficult.

 

>why we created Smart Setup and tried to make it as flexible and fast as possible.

I totally understand your motivation here.

We exposed both sides of the coin (I also presented tutorials, facts and screenshots). Let people decide what they will choose. No need to argue anymore. 

Edited October 8 by GabrielMoraru

[adrian gallero 0]

Not really willing to argue (everyone can use what they prefer and that's ok), but I wanted to chime in for some clarifications.

 

 

On 10/8/2025 at 3:01 AM, GabrielMoraru said:

> You want to ctrl+click an identifier from a 3rd party library and have the IDE Code Insight navigate to its source code? You have to add the folders of the source code to Browse Library Path so Code Insight and debugger can properly find the unit you need to open and show it to you.

Of course. Your alternative would be to add the source code of ALL your 3rd party libraries to your project: same amount of work but sloppy (IF you work with large projects).

 

>Wrong. Again a generalization. 

No. It is not. It is backed up by facts. TMS is not using $auto. See: fact.

This is not really a fact. Tms is using $AUTO (and $ProductVersion, because $AUTO alone is not enough). We are already using it in a lot of products, and the plan is to migrate all products as time allows. Of course, this is not something that can support Delphi < 10.4 (Delphi 11 to be realistic, as auto was introduced in the middle of 10.4 cycle and was buggy at the start). Some of our products support Delphi 7 and newer, so we **also** need to support separate packages too. Our approach is to have folders like

```

  drio

  dsydney

  d11+

```

So we can still support older versions for people that need it, and have newer versions supported by a single package. Also, while normally there aren't breaking changes in the dproj format, sometimes they happen (The DebugInformation switching from a boolean to an integer is the first that comes to mind, but there were others). In that case, you **need** to provide newer packages anyway. So if say Delphi 17 happens to need newer packages, with smart setup you would have the folders:

```

  drio

  dsydney

  d11+

  d17+

```

See https://doc.tmssoftware.com/smartsetup/guide/creating-bundles.html#supporting-multiple-delphi-versions-with-the-same-package

 

 

On 10/8/2025 at 3:01 AM, GabrielMoraru said:

Actually TMS is one of the libraries that makes migration to a new edition of Delphi difficult.

I think you might be confusing "Tms libraries" with "Tms vcl component pack"?  Tms has a lot of products, and many of them are already using $auto. VCL component pack isn't yet, but it will eventually. 

All the products I mantain, and the ones wagner mantains too are already using auto. This is for example the folder structure for packages for TMS FlexCel Studio:

 

You can see there is a D12+ folder there, and not D13. This is because D12 and D13 share the same packages (D11 doesn't because there were some changes that didn't allowed it)

Inside D12+, you will find a 23.0 and a 37.0 folder for D12 and D13 dcus.

 

[adrian gallero 0]

Looking again, sorry, I said that "tms vcl ui pack" doesn't have $(AUTO), but it does. In fact, all products in tms are using $(auto) today:

 

 

What tms ui pack doesn't yet support is the "D11+" notation, so it comes with D13 packages separated from D12 even when they could be the same. It doesn't also send the dcus to $(ProductVersion)\$(Platform)\$(Config), just to  $(Platform)\$(Config) as seen in the screenshot. This is something that will change and eventually all tms products will use Dn+ notation, but the way you use it, all tms products including tms ui pack should work without redownloading. Just recompile the D12 packages in D13.

[Uwe Raabe 2233]

I know I am late to the party, but the slowness of this forum during the last days made me think twice before posting anything.

 

First let me tell you that I am in the concise project party - I can take a vanilla Delphi installation, pull and check out a project repository and have all dependencies inside the project folder structure using Git submodules. This turned out to be the most effective approach allowing individual branches holding project specific tweaks.

 

Usually I have the global IDE library path reserved for Delphi units only. This forces me to actively add any newly used library to the submodules and project search path, which always starts a reasoning whether the inclusion of that library is actually worth it. The latter keeps the dependencies low on the long run.

 

In the past, mostly for simplicity, I added the source paths for these projects, requiring to compile all libraries with each build. This counts for each project, because each uses a different Unit output directories to keep the compiled units separated (think of different conditionals). Unfortunately, since a couple of years we have had some Delphi versions that forced me to start a complete build more often than I anticipated. That raised my interest in the concept of pre-compiled units.

 

To get some numbers to compare the benefits of this approach I took a project group of some relative small projects, changed that to pre-compiled units and compared the build times and other performance changes when working with the project.

 

First I needed to create a batch that actually does the pre-compilation after checking out the libraries. I didn't expect that to be the task taking the most effort. To be Delphi version agnostic I had to prepare proper packages and project groups for some libraries. Then I created an MSBuild project file with the project groups of all used libraries, so that I can call MSBuild once for a platform and configuration in a batch file with MSBuild using BuildInParallel, setting DCC_DcuOutput to a common folder. Having this all working correctly (I had to add copying the .dfm and .res files to the project, too), the time to build all libraries for one platform and configuration lasts about 15 seconds, adding up to a less than half a minute for Win32 and Debug/Release.

 

For simpler maintenance of the project search paths I already used an option set, so changing the list of all the the libraries source folders to the one dcu folder was quite a simple task. It even survives changing to a new Delphi version: ..\lib\dcu\$(ProductVersion)\$(Platform)\$(Config) (As some may note: I have all projects a the source root allowing to have the same relative folders).

 

The build time for one of the most used projects reduced from ~10 seconds to ~4 seconds. That doesn't sound much, but it adds up. And it has way more consequences during working at the code.

• I rarely see the CodeInsight progress bar anymore and when it is just for a glimpse.
• Also LSP seems much more stable and has to be restarted less often. (Sometimes restarting doesn't even help and it turns out I actually made a mistake myself.)
• More and more I get away with a plain compile instead of a build. (Probably I only do a build out of habit)
• MMX Source Indexer is much faster. Instead of 3000 files it now has to scan just 600.

All these effects, even if each is small, add up to a significant faster and smoother working experience.

 

I am aware that using the IDE library path approach includes some of these benefits, too. Nevertheless, I still prefer the concise project approach. Also I want to avoid having libraries in the search paths for all projects of which only a small part makes use of.

[FredS 141]

6 hours ago, Uwe Raabe said:

First let me tell you that I am in the concise project party - I can take a vanilla Delphi installation, pull and check out a project repository and have all dependencies inside the project folder structure using Git submodules. This turned out to be the most effective approach allowing individual branches holding project specific tweaks.

Sure, but doing that deprives you of the "pleasures" of recurring and fleeting bugs..
 

No doubt source path salad issues have amplified since at least Berlin..

[Anders Melander 2137]

1 hour ago, FredS said:

No doubt source path salad issues have amplified since at least Berlin..

Berlin? I thought we were talking about Delphi.

- but why do you say they have amplified?

[FredS 141]

16 minutes ago, Anders Melander said:

Berlin? I thought we were talking about Delphi.

Berlin = Delphi 10.1

 

Quote

- but why do you say they have amplified?

- source is added for every Getit install

- dcu scans seem to go flaky at times when switching config leaving untraceable errors
- using a clean.bat that deletes all but the current config dcus eliminated those

 

A few more but I don't expect any changes to be implemented so I simply limit them via path management.

 

 

 

 

[Anders Melander 2137]

8 minutes ago, FredS said:

Delphi 10.1

Then say so. Saves one having to google what the code name correspond to.

 

10 minutes ago, FredS said:

- source is added for every Getit install

- dcu scans seem to go flaky at times when switching config leaving untraceable errors
- using a clean.bat that deletes all but the current config dcus eliminated those

Okay. I don't use GetIt at all, but don't really have any problems with dcus.

 

I regularly (many, many times a day) switch between 32- and 64-bit, debug and release without problems. I always do a full build after a switch.