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 15 hours ago by pyscripter

[GabrielMoraru 55]

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 15 hours ago by GabrielMoraru

[GabrielMoraru 55]

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 15 hours ago by GabrielMoraru

[GabrielMoraru 55]

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 15 hours ago 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 14 hours ago 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 55]

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 2 hours ago by GabrielMoraru