Add ability to block libs in folder and specify where the deployed libs should be saved

[f4rez]

Needed to add some functionality to match our needs and thought that someone else might want the same functionality.

So to understand why this functionality might be needed I'll give an example.
If you have a ecosystem with several apps that share some libraries looking like this:
Ecosystem
|--AppA
| |--bin
| | |--AppA
| |--lib
| | |--libA.so
|--AppB
| |--bin
| | |--AppB
| | -lib
| | |--libB.so
| --Core
| | --lib
| | |--libCore.so

Both AppA and AppB have a dependency towards libCore.so, to the libs inside the lib-folder and against other libs like Qt.
To not deploy Qt once for each app we instead want to be able to create a folder inside the folder Ecosystem named lib or systemlibs and deploy all libs in this folder. This is added by the "save-lib-path" flag where you specify the relative path from the folder below the binary path.

And to keep the lib structure clean and divided we want to be able to say that libs that lies inside the Ecosystem shouldn't be deployed, this demands that the programmer have fixed the Rpath of the bin before running the program and then the new folder with all the newly deployed libs will be appended to Rpath using $ORIGIN. This is added by "-exclude-folder" that take a absolute path to a folder and any libs inside it won't be deployed.

This might just be something that we need on our code base, but sharing i caring!

[f4rez]

Sorry that there is several unnecessary commits and two features in the same PR, made it work for us and then figured someone else might need it. Otherwise it would have been two PR.

[TheAssassin]

Adding complex features like these always yields the question "does this make it more difficult for people to use the application?". The less flags, the less potential for wrong usage.

May I ask why didn't you just install AppA and AppB into the same prefix, and ran linuxdeployqt with .../AppA ... -executable .../AppB? Seems like the way to go, less work, works with the existing linuxdeployqt feature set, ... Is there anything that prevents you from doing so? If yes, could you describe your user story so we know in which cases these new features would be required?

[f4rez]

I totally agree on the fact that more features can be bad for the user.

it almost works for us with using -executable (have to say that i hadn't looked into it so much before) or it works but there will be some manual labor due to our architecture. We have libraries that are loaded in dynamically using dlopen. These dynamically loaded libs might have a dependency towards either a lib in AppA if we're talking from my previous example or to some external lib that will be deployed by either AppA or AppB.

If the build order always remains the same the rpath of the dynamically loaded lib can point to AppA/lib and it will work. But if we want to only deploy AppB the Rpath have to be changed manually in either the build or using patchelf. And since it's not just two apps and one lib the build precess will be a lot more work.

So if you have some ideas on how to solve this with the existing functionality I'm very open to suggestions.
Changing the architecture will probably not be possible though due to cost and time.

It may be that you believe that were a very small use case and then we'll maintain a fork until we have time for a change in our architecture.

[TheAssassin]

So, basically, you have libraries in AppA/lib which would interfere with libs from AppB/lib and vice versa. All right, that sounds like a valid user story.

[probonopd]

If I get this right, this would introduce dependencies on libraries outside of the AppDir to libraries that do not come with the target systems (Linux distributions) as part of the default installation. One would have to not only download the application, but also the matching Qt runtime.

If so, then this is something I don't want to introduce. There are already plenty of systems (e.g., snappy) which work that way. linuxdeployqt is about generating bundles that are standalone and only require what can safely be assumed to be available on each target system (distribution), like macOS apps work.

Why not put all applications that belong to the same ecosystem into the same AppDir?