Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to use DCMAKE_INSTALL_LIBDIR flag in cmake? #14

Open
kevinsmia1939 opened this issue Apr 18, 2020 · 6 comments
Open

How to use DCMAKE_INSTALL_LIBDIR flag in cmake? #14

kevinsmia1939 opened this issue Apr 18, 2020 · 6 comments

Comments

@kevinsmia1939
Copy link

Hello,

I am trying to package libmsym into openSUSE Leap and Tumbleweed.
I use cmake and gcc to compile the package.

I tried add the cmake flag as follow:
%cmake -DMSYM_BUILD_PYTHON:BOOL=ON
-DCMAKE_INSTALL_PREFIX=/usr/lib64

Which would place the library in /usr/lib64

However, the openSUSE's repository maintainer noticed that the flag is not correctly labeled, it should instead be
%cmake -DMSYM_BUILD_PYTHON:BOOL=ON
-DCMAKE_INSTALL_LIBDIR=/usr/lib64

For placing library in /usr/lib64
But -DCMAKE_INSTALL_LIBDIR don't seems to do anything.

Thanks.
https://build.opensuse.org/request/show/795267

@mcodev31
Copy link
Owner

Hi Kevin,

I’m not a cmake expert, but I suspect you mean -DCMAKE_INSTALL_LIB_DIR (note the underscore). I can’t try this since I don’t have access to a computer right now.

On a more general note, it may be easier to distribute the c lib as a separate package from python (e.g. python-libmsym), and add a dependency, since the cmake python options are meant to handle cases here libmsym.so can’t be found by the loader (which it should in /usr/lib64). Also the plan was to add bindings for more languages at some point.

/M

@kevinsmia1939
Copy link
Author

Hello,

I just tried -DCMAKE_INSTALL_LIB_DIR, it does not seems to do anything.

For splitting package, you mean to create a 2 package that have -DMSYM_BUILD_PYTHON:BOOL=ON and -DMSYM_BUILD_PYTHON:BOOL=OFF and called the BOOL=ON python-libmsym?

@badshah400
Copy link

The standard cmake flag is CMAKE_INSTALL_LIBDIR, not CMAKE_INSTALL_LIB_DIR, please see
https://cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html. The advantage of using the former is that it is defaults to the right FHS directory (lib or lib64 based on architecture). I suspect that because INSTALL_LIB_DIR is explicitly set to lib in the script and then this variable — rather than the standard one — is used as the target for installation, the user is unable to configure the installation directory simply by passing a flag to the cmake command. Actually, they can still use CMAKE_INSTALL_PREFIX, but that is wrong.

@kevinsmia1939
Copy link
Author

Even with
%cmake -DMSYM_BUILD_PYTHON:BOOL=ON
-DCMAKE_INSTALL_LIBDIR=/usr/lib64

or

%cmake -DMSYM_BUILD_PYTHON:BOOL=ON
-DCMAKE_INSTALL_LIB_DIR=/usr/lib64

could not get it to install to /usr/lib64 only the below flag works.

%cmake -DMSYM_BUILD_PYTHON:BOOL=ON
-DCMAKE_INSTALL_PREFIX=/usr/lib64

@mcodev31
Copy link
Owner

@badshah400
Again, this isn't really my area but at the time this was written, it wasn't certain that I could keep the cmake 2.8 dependency since one of the qc software using this only had a dependency on 2.6 (old clusters difficult to upgrade). So I went with what seemed to be convention at the time for 2.6. Beleive I looked at zlib, which still uses a similar approach.

@kevinsmia1939
I'll try to get around to switching to GNUInstallDirs soon, but I won't be doing much coding for at least a couple of weeks.

@kevinsmia1939
Copy link
Author

@badshah400
Again, this isn't really my area but at the time this was written, it wasn't certain that I could keep the cmake 2.8 dependency since one of the qc software using this only had a dependency on 2.6 (old clusters difficult to upgrade). So I went with what seemed to be convention at the time for 2.6. Beleive I looked at zlib, which still uses a similar approach.

@kevinsmia1939
I'll try to get around to switching to GNUInstallDirs soon, but I won't be doing much coding for at least a couple of weeks.

Alright, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants