A library path manager...

[dkounal 3]

I can not afford any more the "Can not load package" error message after installations that use DCC command line.

I have a long library path with many components installed and an error like the following is presented again:

warning MSB6002: The command-line for the "DCC" task is too long. 
Command-lines longer than 32000 characters are likely to fail. 
Try reducing the length of the command-line by breaking down the call to "DCC" into multiple calls with fewer parameters per call.

this mean that I should remove paths from library path in the IDE and try to compile again and return them back.... a bit annoying....

Also, I hate to go to every combobox selection to add a path.

The attached program reads registry and allows you to enable or disable library paths, add paths to all configs or remove from all configs.

When saving it produces an .ini file with all paths (even these that are not enabled) to be used in the next time it runs

 

No responsibility for anything, use it at your own risk, keep a backup of 'CurrentUser\SOFTWARE\Embarcadero\BDS\xxx\Library\' before using it, source at request, have a nice day!

LibManager.zip

[Guest]

My killer tip: (I always use games and software that insist on creating their subfolders in system folders such as: Programs Files (x86 or not), among other places, such as: 😄 \ User \ .... ( long tree of folders)

1. Install the software normally
2. MSWindows has a very useful tool for these moments, its name: MKLINK
3. I create my "Link Symbolic" for folders with very long names or that are in a tree of many levels.
   1. MKLINK / d / j "name-to-new-link-symbolic" "c:\name-target-directory"
      1. Of course, firstly, I create one root-folder in any other place (or disk) to copy all in the directory that will be replaced.
      2. ex.:   C:\Program Files\My Company\My Software\My Version\etc...   ---> will stay:   C:\Program Files\MyShortName
         1. first, I'll COPY all sub-folder and files -->  C:\Program Files\My Company\*.*     to   D:\MKLinks\MyCompany
            1. now it's possible delete all in this folder ...\My Company\*.* - include it!
         2. CD C:\Program Files
         3. MKLINK /d /j "My Company"   "D:\MKLinks\MyCompany"
         4. It's ready!
         5. in my PATH = %PATH%;"C:\Program Files\My Company"
   2. NOTE: use the absolute path, including the drive letter!
      1. Normally, the software try find your files and sub-folders in particular folder, then, is necessary usar the original name for first-root folder
4. this way, I decrease the "bytes" of my "PATH" variable.
5. for me it works, so it must work for others too!
6. Of course, here is simple sample! Normally, I have my games on Drive"E", and, all folders with saves, config, etc... in my Drive"D". Then, I can delete, format, etc... my Drive"E", and my "saves-game" is in safety!
7. For RAD Studio, I have same tatic: 
   1. RAD Studio in C:\Emb\Studio\200
   2. Component Suites in: C:\Emb\FR  (to FastReport) etc...
8. The secret is: DONT USE SYSTEM FOLDERS LIKE "Programs Files...." - when it's possible!

Edited December 19, 2020 by Guest

[dkounal 3]

That's a good solution too, for many other situations.

Agreed and thank you.

One day, the limit arrives to this solution, too. I have 3 to 5 letters dirs, but installation programs still change path in updates and add again the path they want.....

Not all the components are used at the same time. I can not afford to install and de-install them, to go behind each update to see what happened.

I needed something else. Now the limit is the IDE itself.

Edited December 19, 2020 by dkounal

[Guest]

yeah, you know:

• the developers create long tree-folders because in they machine, all it's works! but... in another pc, is another history!
• thanks to Microsoft we have big folder-names in big folder-tree

 

[dummzeuch 1517]

Another option is to use relative paths and have all libraries as a subdirectory of the project. As they belong into source control anyway, we are using svn:external for that. Works fine for libraries and less well for components since the IDE does not support it really and most component installers insist on using a global directory.

[David Heffernan 2353]

1 minute ago, dummzeuch said:

Another option is to use relative paths and have all libraries as a subdirectory of the project. As they belong into source control anyway, we are using svn:external for that. Works fine for libraries and less well for components since the IDE does not support it really and most component installers insist on using a global directory.

This seems like a much better approach to me. 

 

And as soon as you have to deal with different versions of a library, then aren't you forced this route? 

[dummzeuch 1517]

4 hours ago, David Heffernan said:

This seems like a much better approach to me. 

 

And as soon as you have to deal with different versions of a library, then aren't you forced this route? 

As I wrote: This works find for libraries. Components are a problem, because they are installed globally. There are various solutions for that too, e.g. custom registry branches, but they are a pain in the lower back anyway.

[Anders Melander 1815]

4 hours ago, David Heffernan said:

This seems like a much better approach to me.

And as soon as you have to deal with different versions of a library, then aren't you forced this route? 

Indeed.

All paths relative and everything it source control. This also makes it trivial to build the project on a build server.

 

At my current client the main product used to have dependencies on 5-6 different Git repositories and a bunch of 3rd party libraries that wasn't under source control. One person was responsible for figuring out what revision to checkout from the different repositories and what version of the 3rd party libraries to install and then build a version that could be sent to QA or deployed to the customers. And of course there were no relative paths. It was a nightmare.

I moved everything into Git, made the dependent repositories submodules of the project repository, adding the source of the 3rd party libraries (also as submodules) and made all the paths relative. It took a few days to set up and now we have a fresh build after each commit.

 

26 minutes ago, dummzeuch said:

Components are a problem, because they are installed globally. There are various solutions for that too, e.g. custom registry branches, but they are a pain in the lower back anyway. 

Wouldn't it be great if the project package configuration actually worked like most people expect it to (i.e. only load the packages specified in the project settings) and we could specify a (relative) path to the packages?

I wouldn't even mind if I had to restart Delphi to switch from one project to the next. It would be better than the current situation.

[David Heffernan 2353]

18 minutes ago, Anders Melander said:

Wouldn't it be great if the project package configuration actually worked like most people expect it to (i.e. only load the packages specified in the project settings) and we could specify a (relative) path to the packages?

I wouldn't even mind if I had to restart Delphi to switch from one project to the next. It would be better than the current situation.

It's kinda lame that they still haven't addressed this. It's been an issue since Delphi 1. The tech exists. They can already dynamically load and unload packages. 

[Uwe Raabe 2064]

That is exactly what I tried to address with Package Magician. Unfortunately some poorly programmed packages just refuse to unload correctly, which sabotages the task of Package Magician.

[Anders Melander 1815]

3 hours ago, Uwe Raabe said:

That is exactly what I tried to address with Package Magician.

Yes, exactly like that. Now you just need to convince Embarcadero to integrate it with the IDE. I haven't tried it yet as I wasn't too happy about adding one problem (an external dependency) to fix another one. I'll give it a try now anyway.

 

3 hours ago, Uwe Raabe said:

Unfortunately some poorly programmed packages just refuse to unload correctly, which sabotages the task of Package Magician. 

I guess that should be fixed by the authors. Did you try to make that happen?

[Guest]

@Dave Nottage  and @dummzeuch  thanks your thanks 

Edited December 19, 2020 by Guest

[dummzeuch 1517]

17 hours ago, Uwe Raabe said:

That is exactly what I tried to address with Package Magician. Unfortunately some poorly programmed packages just refuse to unload correctly, which sabotages the task of Package Magician.

Now that you mentioned it, I remember that I always wanted to try that tool as soon as I move to a more recent Delphi version...