Proper behaviour and use of CMAKE_INSTALL_* variables

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Proper behaviour and use of CMAKE_INSTALL_* variables

Mojca Miklavec
Dear list members,

I often like or need to install two versions of the same software.
Ideally the software should put its files by default to
    $prefix/include/$NAME/*.h
    $prefix/lib/$NAME/*.dylib
    ...
($prefix => $CMAKE_INSTALL_PREFIX)

and in order to be able to install multiple versions side-by-side I
would like to be able to specify something like
    -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION
    -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION
to end up with
    $prefix/include/$NAME/$VERSION/*.h
    $prefix/lib/$NAME/$VERSION/*.dylib
instead of default paths.

The problem is that in this case either of the two options must be true:

a) Software sets CMAKE_INSTALL_INCLUDEDIR to "include/$NAME" rather
than to "include" by default which "violates" the convention from
http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:GNUInstallDirs,
but leads to the desired behaviour.

b) Software sets CMAKE_INSTALL_INCLUDEDIR to "include" by default and
automatically adds "$NAME" to an internal variable when installing the
files. The drawback of this approach is that
    -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION
results in files being installed to
    $prefix/include/$NAME/$VERSION/$NAME/*.h
and there is absolutely no way to change that.


What approach would you suggest to achieve the desired behaviour
without violating the conventions?

Thank you very much,
    Mojca
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Proper behaviour and use of CMAKE_INSTALL_* variables

Andreas Pakulat-2
Hi,

On Mon, Dec 9, 2013 at 3:50 PM, Mojca Miklavec <[hidden email]> wrote:
Dear list members,

I often like or need to install two versions of the same software.
Ideally the software should put its files by default to
    $prefix/include/$NAME/*.h
    $prefix/lib/$NAME/*.dylib
    ...
($prefix => $CMAKE_INSTALL_PREFIX)

and in order to be able to install multiple versions side-by-side I
would like to be able to specify something like
    -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION
    -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION
to end up with
    $prefix/include/$NAME/$VERSION/*.h
    $prefix/lib/$NAME/$VERSION/*.dylib
instead of default paths.

Do you have any reasons that speak against using separate prefixes for each version of that software? In particular since such a setup will make your life harder when you want to use the installed software in some cmake-based project. In that case you'd have to manually specify include-dir and lib-dir when configuring the project since many find-modules simply expect a 'standard' unix-like layout below the prefix under which they should search for a given software. So they don't look into include/<version> or lib/<version> so you'd need to specify that manually. Compared with the ease of just specifying CMAKE_PREFIX_PATH to the installation directory for the version you want thats a lot more effort each time you setup a build directory.

Andreas 


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Proper behaviour and use of CMAKE_INSTALL_* variables

Mojca Miklavec
On Mon, Dec 9, 2013 at 4:52 PM, Andreas Pakulat wrote:

> Hi,
>
> On Mon, Dec 9, 2013 at 3:50 PM, Mojca Miklavec wrote:
>>
>> Dear list members,
>>
>> I often like or need to install two versions of the same software.
>> Ideally the software should put its files by default to
>>     $prefix/include/$NAME/*.h
>>     $prefix/lib/$NAME/*.dylib
>>     ...
>> ($prefix => $CMAKE_INSTALL_PREFIX)
>>
>> and in order to be able to install multiple versions side-by-side I
>> would like to be able to specify something like
>>     -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION
>>     -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION
>> to end up with
>>     $prefix/include/$NAME/$VERSION/*.h
>>     $prefix/lib/$NAME/$VERSION/*.dylib
>> instead of default paths.
>
>
> Do you have any reasons that speak against using separate prefixes for each
> version of that software?

First, both versions of the software *have to* to be installed under
$prefix (in my case that is usually /opt/local) because that is the
location where all the packages installed by a specific package
manager (MacPorts) need to end up. What I could do is to install the
two versions under
    CMAKE_INSTALL_PREFIX=$prefix/Library/Frameworks/$NAME.framework/Versions/$VERSION/
even if the software doesn't really satisfy the layout of a framework,
but that layout doesn't really simplify that much other than no need
to specify 5 separate variables to change include, lib, man, doc, ...

> In particular since such a setup will make your
> life harder when you want to use the installed software in some cmake-based
> project.

That's not a really good argument.

Life is already hard. For FindX11 I need to manually specify about 20
different variables to be able to get rid of searching in /usr/X11R6
(Mac OS X) for example and use the libraries from /opt/local instead.
For almost any given library I usually need to specify 2-5 variables
(one for includes and several for each single dylib) and a lot of
FindWhatever.cmake are simply too "stupid" to allow easy
configuration. The pkg-config approach works a whole lot better in a
lot of cases. I would really like to avoid searching in some prefixes
(for example I would like to avoid searching for libraries in
/usr/local and only search in /opt/local), but I don't know any
elegant way to do so.

And in case of some specific software I have in mind, the software
itself provides its own CMake configuration file, so all dependent
packages/software need to do is to find that configuration file,
nothing else.

> In that case you'd have to manually specify include-dir and lib-dir
> when configuring the project since many find-modules simply expect a
> 'standard' unix-like layout below the prefix under which they should search
> for a given software. So they don't look into include/<version> or
> lib/<version> so you'd need to specify that manually. Compared with the ease
> of just specifying CMAKE_PREFIX_PATH to the installation directory for the
> version you want thats a lot more effort each time you setup a build
> directory.

I'm still interested in the answer to my original question and would
like to avoid discussion about why not specifying a different $prefix.
There are surely many pros and contras to each approach and it makes
no sense to get off-topic with a different discussion. (I could surely
write an essay about pros of my approach, but that wouldn't help me
answer my question. I can open a new thread about that if needed, but
let's stick to the original question here.)

Mojca
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake