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

[pyscripter 854]

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 Tuesday at 05:06 PM by pyscripter

[GabrielMoraru 56]

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 Tuesday at 05:24 PM by GabrielMoraru

[GabrielMoraru 56]

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 Tuesday at 05:23 PM by GabrielMoraru

[GabrielMoraru 56]

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 Tuesday at 05:50 PM by GabrielMoraru

[pyscripter 854]

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 Tuesday at 06:13 PM 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 56]

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 Wednesday at 06:15 AM 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.