-
-
Notifications
You must be signed in to change notification settings - Fork 61
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
Added packaging with CPack and generation of pkg-config. #52
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, it looks like a lot of different changes in a single comment. You are at least:
- Adding project description information.
- Changing include path for installed version of library.
- Trying to make the installation architecture independent.
- Adding CPack Scripts
- Adding PkgConfig Information
I would personally like to see all those changes made in separate commits. In particular, I am not convinced of wisdom is complicating scripts to make installs architecture independent (part 3 above). While this looks nice here, in my experience, this complicates the life of package managers, who might want to specify their own changes. However, I can be convinced of this, if someone presents a good logic.
In short, I like 1 and 5. I am not well versed enough to evaluate 4, and I do not like 2 and 3 as of now.
CMakeLists.txt
Outdated
set(PROJECT_HOMEPAGE_URL "https://github.com/bfgroup/Lyra") | ||
|
||
include(GNUInstallDirs) | ||
string(REPLACE "/${CMAKE_LIBRARY_ARCHITECTURE}" "" CMAKE_INSTALL_LIBDIR_ARCHIND "${CMAKE_INSTALL_LIBDIR}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we using CMAKE_LIBRARY_ARCHITECTURE
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is the impl detail of GNUInstallDirs
. CMAKE_INSTALL_LIBDIR
is composed of it and other stuff, usually lib
. I have tried to set it to ""
before including GNUInstallDirs
without any success. IMHO instead GNUInstallDirs
should also create arch-independent vars.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As noted, two big points:
- Not a fan of doing things Arch Independent. Just complicates build scripts for no apparent benefit.
- Do not define variables starting with
CMAKE_
. I want to reject the second line of change. I accept the first part of change which movesGNUInstallDirs
at the top.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please provide tests to ensure the changes are valid.
I don't understand what you mean. I went to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mistakenly approved the changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mistakenly approved everything. Will try to approve at a more granular level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original path is not incorrect. If there is a policy of distributions to do something specific, then we can look at it. Otherwise, no need to change the path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind this change. But the name can be more descriptive. CMAKE_CONFIG_DEST
is not a good name in my opinion. First of all, you should not define any name that starts with CMAKE_
. That space is reserved for cmake
. And secondly. the name should use the same naming pattern as CMAKE_INSTALL_<X>DIR
. So, instead, that name should be LYRA_INSTALL_CONFIGDIR
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for dividing up the commits.
I've marked some minor changes in some commits which I am ready to accept. I've marked commits I don't like as such as well.
CMakeLists.txt
Outdated
@@ -58,7 +58,7 @@ target_include_directories( | |||
# Add an alias to public name. | |||
add_library( bfg::Lyra ALIAS lyra ) | |||
|
|||
set(CMAKE_CONFIG_DEST "${CMAKE_INSTALL_DATADIR}/lyra/cmake") | |||
set(CMAKE_CONFIG_DEST "${CMAKE_INSTALL_LIBDIR}/cmake/lyra") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a policy by distributions to do so? If yes, we might consider it. I do not dislike this change, but I don't want to change just for change's sake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is the convention used in ubuntu and I don't even remember if the previous way have been working
CMakeLists.txt
Outdated
@@ -58,14 +58,15 @@ target_include_directories( | |||
# Add an alias to public name. | |||
add_library( bfg::Lyra ALIAS lyra ) | |||
|
|||
set(CMAKE_CONFIG_DEST "${CMAKE_INSTALL_DATADIR}/lyra/cmake") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not define variables starting with CMAKE_
. Those names are reserved for cmake
. I like this change, but the name has to be better and fir the already existing naming scheme.
I suggest LYRA_INSTALL_CONFIGDIR
as the alternate which I'll be happy with.
CMakeLists.txt
Outdated
@@ -88,7 +88,7 @@ install( | |||
install( | |||
FILES | |||
${PROJECT_BINARY_DIR}/lyraConfig.cmake | |||
DESTINATION ${CMAKE_INSTALL_DATADIR}/lyra/cmake/ | |||
DESTINATION ${CMAKE_INSTALL_DATADIR}/lyra/cmake |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you remove the /
? Any specific reason? I do not want to change lines for change's sake.
packaging/pkgconfig.pc.in
Outdated
@@ -0,0 +1,7 @@ | |||
prefix=@CMAKE_INSTALL_PREFIX@ | |||
includedir=${prefix}/include |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you replace include
with CMAKE_INSTALL_INCLUDEDIR
in original place, you should also replace similar here to be consistent.
set(CPACK_PACKAGE_VENDOR "${PROJECT_NAME} developers") | ||
set(CPACK_PACKAGE_DESCRIPTION "${PROJECT_DESCRIPTION}") | ||
set(CPACK_DEBIAN_PACKAGE_NAME "lib${CPACK_PACKAGE_NAME}-dev") | ||
set(CPACK_RPM_PACKAGE_NAME "lib${CPACK_PACKAGE_NAME}-devel") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure that the CPack command won't fail because it will try to generate packages for every single distribution listed here? May be make sure that the cpack
won't fail on different platforms.
This is something you can write a test for on each platform in the CI. The CI should generate cpack packages and succeed in doing so.
60d09df
to
e766efb
Compare
…riables defined there earlier in the script. Added a variable for path to architecture-independent libs.
…ource of the previous mistake) by introducing a variable `LYRA_INSTALL_CONFIGDIR`
…placed in /usr/<lib dir>[/<arch>]/cmake/<package name> in distros. At least, in Ubuntu and Fedora.
…onfig files should be in an arch-independent location.
…uld be taken from CMake variables.
No description provided.