Installation suffixes problematic on Linux

[matze]

Depending on the build architecture, you append either 32 or 64 to the installation dirs (for example bin32 or lib64). The FHS does not specify such suffixes for binary directories, hence your binaries won't be found on most distributions because something like /usr/bin32 is not in $PATH.

Moreover, appending a 64 to the lib directory should be left for the distributions to decide and should be made configurable and/or overridable. See for example this approach posted on the CMake mailing lists.

[kknox]

Once again, thank you for the feedback; I'm looking into your documentation.

[kknox]

For APPML, we would provide pre-compiled downloadable packages that would bundle both 32bit and 64bit binaries together. We did not want to tag the executables with the 'bitness' to simplify users link commands, so we created directories to disambiguate the various binaries. I've read the FHS, but it does not address a standard for the /bin directories. Would it be an improvement to drop the 32 postfix?
32bit: /bin, /lib
64bit: /bin64, /lib64

With regard to allowing the developer to choose 32bit or 64bit builds, we use this cmake code:

if( MSVC_IDE )
    set( BUILD64 ${CMAKE_CL_64} )
    set_property( GLOBAL PROPERTY USE_FOLDERS TRUE )
else()
    option( BUILD64 "Build a 64-bit product" ON )

        ....
endif()

Are you saying that you want the developer to be able to specify an alternative path in addition to this logic?

[matze]

For APPML, we would provide pre-compiled downloadable packages that would bundle both 32bit and 64bit binaries together.

What's the point in that, actually? In any case, the user has either a 32-bit or a 64-bit system and the binaries would be located in /bin. That's why the FHS does not address bitness for

I've read the FHS, but it does not address a standard for the /bin directories. Would it be an improvement to drop the 32 postfix?

It would be an improvement to drop the postfix altogether.

Are you saying that you want the developer to be able to specify an alternative path in addition to this logic?

Not the path (that's what CMAKE_INSTALL_PREFIX is used for) but a distribution-specific post-fix. The person who knows for what target platform the library is built, is also responsible for deciding where the library goes. For example, a Debian packager would probably like to run

cmake -DCMAKE_INSTALL_PREFIX=/usr $ROOT -DLIB_SUFFIX=/$ARCH

because on Debian/Ubuntu there is no lib64 but soon enough the architecture triplet (i.e. x86_64-linux-gnu), whereas a Fedora packager would like to run

cmake -DCMAKE_INSTALL_PREFIX=/usr -DLIB_SUFFIX=64 $ROOT

for 64 bit packages and leave out a suffix for 32 bit packages.

[kknox]

I have to admit that I still don't get the why FHS does not address the need for a /bin64. If the need for a /lib64 and a /lib is seen as necessary, then that stands to reason that it could be expected that both 64bit and 32bit executables could be installed side by side. Especially for developers who like to build portable software.

Regardless, there may be a solution to make everybody happy, which provides maximum flexibility. If it is handy to define a user configurable LIB_SUFFIX variable to allow users to customize the install logic for their system, then a case could be made for a BIN_SUFFIX variable or some such that served the same purpose for executables. We could make the default a blank string to honor the FHS.

[kknox]

Hi @matze~

I've forked clFFT and checked in modifications to add user setable SUFFIX_LIB/SUFFIX_BIN cache variables (names such that the cmake-gui will group them together). If you have time, please scanthe diffs to see if this is sufficient to address your comment:
https://github.com/kknox/clFFT/compare/clMathLibraries:develop...develop
Sorry about a few other unrelated nmake edits; i was testing with nmake and I tweaked the build files to help debug.

[pavanky]

@kknox

Can you make sure the same changes are being done for the clBLAS library as well ?

[kknox]

Hey @pavanky, i was thinking of upgrading the clblas library next; I just wanted to get a quick review from the OP before I pushed. Do you spot potential issues or concerns?

[pavanky]

@kknox Having SUFFIX_LIB would be useful. SUFFIX_BIN not so much. On linux there aren't many people using 32 bit binaries when a 64 bit version is available (and is working well).

However if you really to support both, you can put the binaries in as /usr/bin/foo/bar.x86 and /usr/bin/foo/bar.x86_64. Then have a script bar as /usr/bin/bar. Then bar --32 can call the 32 bit version, while bar without any options can call the 64 bit version.

[matze]

Sorry for the late reply @kknox, I have been on vacation for a week. The change looks good and useful to me, although @pavanky is kind of right about the binary suffix. Also as far as I can see, the binaries are Python scripts which should are arch-independent and could go into $PREFIX/bin or better be installed by a Python setup.py script.