Upgrading to new RAD Studio vs. project Lib names

[w0wbagger 0]

Hey folks, we've been dealing with this issue for more than a decade, and I'm only now finally asking if there's an elegant solution for updating my project files when we upgrade RAD Studio version.  We use a few 3rd party libraries (Devart, DevExpress, ICS), and every time we upgrade, the library file names change (for example from libXXXR28 to libXXXR29). Generally, this means we have to find everywhere in our project file that the old library files are referred to and update them. Is there an easier way of doing this? If we just create a brand new project with all of the original source files, will it automatically add the .lib files the project requires? How *does* RAD Studio identify which of the installed .lib files are required in a project?

Thanks in advance for any advice on how you migrate your projects to the most recent version of RAD Studio.

 

 

[Vincent Parrett 720]

This is a pet peeve of mine, library authors and package naming - not using LibSuffix in their packages and adding the version to the package names.

 

If you are not using runtime packages (most people don't) - then the IDE doesn't really track what is used by the project - it just uses the Library path and project Search path to make those libraires available. 

 

I have been working on a solution for a while - a package manager -  still a work in progress but getting there - see delphi.dev - it will need library author/vendors to create packages to make it work though. 

 

DPM does store the package references in the dproj file - when you load up the project in a new version of RAD Studio (and the ide plugin is installed) - it will automatically download and install the dpm packages (assuming there are versions available for the new delphi version).  

[Vincent Parrett 720]

wrong topic - deleted

Edited August 5 by Vincent Parrett

[w0wbagger 0]

@Vincent Parrett, I'm using C++ Builder, and the issue for us really stems from the massive list of .lib files passed to ilink. We don't use runtime packages, so our project files have a big list of libs, the names of which are almost all changed for the new version of RAD studio. This program is at least two decades old, and each time we've upgraded from Borland C++ 6, to Codegear, to Embarcadero, we have to modify the .proj file. Was just wondering if there's an easy way to have RAD Studio add all .libs for all installed packages to a project file. There has to be a better way than what we've had to do over the years.

Thanks for your response. 

[Vincent Parrett 720]

Ah ok, C++Builder is not my expertise - but the comment about libsuffix still stands when it comes to lib files - the vendors are at fault if their lib file names change for each version of rad studio. 

 

The only way I know of to whittle down the list if libs is to remove them all and keep adding back until it compiles. 

[w0wbagger 0]

Yeah, that was what I feared. If I strip the .libs back to absolutely nothing, do you know if there is a way to find the filename of the lib that contains the function that is preventing the linker from linking? [Obviously not for 3rd party libs, but maybe at least RAD Studio has a resource that says "function XX is in library YY, with filename ZZ"]? Thanks for your suggestions. 

 

[Vincent Parrett 720]

I can only suggest looking at the dpk files in the rs source folders - e.g BuildWinRTL.dpk - seems like they didn't ship dpk's for anything other than rtl. You might be able to use tdump.exe to get a list of files from the .lib files.

 

 

[Remy Lebeau 1339]

13 hours ago, w0wbagger said:

maybe at least RAD Studio has a resource that says "function XX is in library YY, with filename ZZ"]?

Nope. The documentation mentions the unit name and header file, but not the lib file. 

[RobinP 1]

Just been doing the 11.2 to 12.2 upgrade.  Yes it's a pain but not too bad, here's what I did:

 

1. Build one project in the new IDE.  Tick yes to remove the old components. 

2. To fix any linker errors drop one of the now missing components on the main form.  Repeat until it builds.

3. Revert all changes to the main form.

 

You should now just have an updated project file, from which you can tell both the old and new names, so:

4. Use a Python script update all other project files.