#116 PREFIX not respected in subdirs projects

[Alexander Schnaidt]

When passing PREFIX to qmake the variable is not respected in xflr5-engine.pro
or XFoil-lib.pro where 'target.path' is hardcoded to "/usr/local/lib".
This results in the binary 'xflr5' being installed in the correct PREFIX while the libraries end up in /usr/local/lib.

[André]

Well, /usr/local/lib is where the shared libraries belong if they are to be re-used by other applications.
But OK, I'll see if this can be overriden if PREFIX is specified.

[Alexander Schnaidt]

Most linux distributions, whether they follow the FHS or just out of convention, reserve /usr/local for locally installed software that bypasses the package-manager. Official distro packages will not be installed there

So instead of letting every downstream packager hack around this individually it would be better to fix it upstream before they start packaging 6.42.

[Alexander Schnaidt]

Debian follows the FHS:
https://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#USRLOCALLOCALHIERARCHY

as well as Fedora:
https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fusr.2Flocal.2C_or_.2Fhome.2F.24USER

Gentoo's layout is only based on the FHS but retains the same rule for /usr/local:
https://devmanual.gentoo.org/general-concepts/filesystem/index.html

same as Arch:
https://wiki.archlinux.org/index.php/Arch_packaging_standards#Package_etiquette

[André]

I'm not very good at packaging for linux. Care to commit the change if I give you dev rights to the project?

[Alexander Schnaidt]

Commit access is probably a bit too much responsibility but i can try to whip up a patch this weekend.

[Alexander Schnaidt]

I think this is as idiomatic as it gets in qmake. I tested it for a couple of scenarios and it seems to work as expected. It still defaults to /usr/local but will let you override the prefix with a simple "qmake PREFIX=/usr".

[André]

Thanks. I'm still uncertain though.
I understand that it's important to facilitate the job of packagers. However the goal is for the XFoil-lib and xflr5-engine libs to be re-used by other apps, say sail7 for instance. If they are installed in any directory, then this directory will need to be included in the user's PATH, and as far as I understand the make install process doesn't do this - by default at least.
On the other hand, again as far as I understand, this is the intent of the /usr/local/lib directory. from The Linux Documentation Project

/usr/local
The original idea behind '/usr/local' was to have a separate
('local') '/usr' directory on every machine besides '/usr', which
might be just mounted read-only from somewhere else. It copies the
structure of '/usr'. These days, '/usr/local' is widely regarded as
a good place in which to keep self-compiled or third-party programs.
The /usr/local hierarchy is for use by the system administrator 
when installing software locally. It needs to be safe from being
overwritten when the system software is updated. It may be used for
programs and data that are shareable amongst a group of hosts, but
not found in /usr. Locally installed software must be placed within
/usr/local rather than /usr unless it is being installed to replace
or upgrade software in /usr.

The main advantage is that /usr/local/lib is in the PATH by default.
The other recommended way seems to be to use the opt directory

/opt
This directory is reserved for all the software and add-on packages
that are not part of the default installation. For example,
StarOffice, Kylix, Netscape Communicator and WordPerfect packages
are normally found here. To comply with the FSSTND, all third party
applications should be installed in this directory.

But then the install process will need to add the directory to the PATH.
I'll give it some thought.

[Alexander Schnaidt]

The goals of reusable xflr libraries and happy downstream packagers are not at odds.

Any software worth its money will default to the /usr/local PREFIX. Admins expect this when they install software with the typical "make && make install" combo.
Distribution packagers must follow the guidelines of their distro, which in most cases forbids installation to /usr/local.

You, as the upstream maintainer, don't have to worry about /usr/local/lib being in the search path of the dynamic linker or /usr/local/bin being in $PATH. Leave that up to the distribution and the admin, they know better about the quirks of their system.
The best thing you can do is to keep the build system adaptable enough to help them achieve their respective goals.

The main advantage is that /usr/local/lib is in the PATH by default.

You can't rely on this being true. But you don't have to worry about it either. It's not your problem, leave it up to the distro/admin.

/opt

Since this project nicely fits into the file structure of modern distros you don't want to install to /opt.

[André]

OK, thanks for the exaplanation. Things are a little more clear now.

[André]

Fix committed.