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

CMake version config file is architecture-dependent #1697

Closed
uhoreg opened this issue Aug 1, 2019 · 9 comments · Fixed by #1746
Closed

CMake version config file is architecture-dependent #1697

uhoreg opened this issue Aug 1, 2019 · 9 comments · Fixed by #1746
Assignees
Labels
kind: bug release item: 🔨 further change solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Milestone

Comments

@uhoreg
Copy link
Contributor

uhoreg commented Aug 1, 2019

CMake's write_basic_package_version_file by default creates a file that checks that the word size is the same as the word size used when the file was created. That means that if the file was created on a 64-bit machine, then CMake will refuse to use it on a 32-bit machine (or vice versa). This is a problem for the Debian package, since the package is architecture-independent, and so it is only built once on one architecture, and that package used when building other packages on other architectures. See, for example, https://buildd.debian.org/status/fetch.php?pkg=nheko&arch=i386&ver=0.6.4-1&stamp=1564680125&file=log in which it tries to build a package on a 32-bit architecture, using the JSON library package built on a 64-bit architecture.

In CMake 3.14, they added a ARCH_INDEPENDENT flag to write_basic_package_version_file to drop this check. However, if you use that, it would require bumping the minimum version of CMake to 3.14. This also doesn't help us in Debian, since we still have CMake 3.13. For Debian, I've worked around this for now by creating my own template for nlohmann_jsonConfigVersion.cmake:

set(PACKAGE_VERSION "@PROJECT_VERSION@")

if(PACKAGE_VERSION VERSION_LESS PACKAGE_FIND_VERSION)
  set(PACKAGE_VERSION_COMPATIBLE FALSE)
else()

  if(PACKAGE_FIND_VERSION_MAJOR STREQUAL "@PROJECT_VERSION_MAJOR@")
    set(PACKAGE_VERSION_COMPATIBLE TRUE)
  else()
    set(PACKAGE_VERSION_COMPATIBLE FALSE)
  endif()

  if(PACKAGE_FIND_VERSION STREQUAL PACKAGE_VERSION)
      set(PACKAGE_VERSION_EXACT TRUE)
  endif()
endif()
@nlohmann
Copy link
Owner

nlohmann commented Aug 3, 2019

Would you mind opening a PR?

@uhoreg
Copy link
Contributor Author

uhoreg commented Aug 6, 2019

Sure, I can do that. Would you prefer bumping the CMake version requirement to 3.14 so that the ARCH_INDEPENDENT flag can be used, or using the template that I adapted for Debian?

@nlohmann
Copy link
Owner

nlohmann commented Aug 6, 2019

Definitely not bumping the required CMake version.

@stale
Copy link

stale bot commented Sep 5, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Sep 5, 2019
@uhoreg
Copy link
Contributor Author

uhoreg commented Sep 5, 2019

Hi, I'm still alive, and will write a PR, but was on vacation for most of August.

@stale stale bot removed the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Sep 5, 2019
@stale
Copy link

stale bot commented Oct 5, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Oct 5, 2019
@uhoreg
Copy link
Contributor Author

uhoreg commented Oct 6, 2019

Hi stale bot, I made a PR to fix this issue.

@stale stale bot removed the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Oct 6, 2019
@stale
Copy link

stale bot commented Nov 5, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Nov 5, 2019
@stale stale bot closed this as completed Nov 12, 2019
@nlohmann nlohmann added release item: 🔨 further change solution: proposed fix a fix for the issue has been proposed and waits for confirmation and removed state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated labels Apr 19, 2020
@nlohmann nlohmann self-assigned this Apr 19, 2020
@nlohmann nlohmann added this to the Release 3.8.0 milestone Apr 19, 2020
@nlohmann
Copy link
Owner

Fixed by merging #1746

Tachi107 added a commit to Tachi107/nlohmann-json that referenced this issue Jul 28, 2022
As nlohmann_json is a header-only library, its pkg-config and cmake
config files should be installed to `share/` (GNUInstallDirs' DATADIR),
as `share/` is the canonical directory where architecture-independent
files should be stored, while `lib/` is for architecture-dependent stuff
(see the [FHS][]).

Apart from being technically correct, installing to `share/` can help
with cross-compiling, for example in Debian-based environments. If
you're interested, I'd suggest reading this [thread][].

Related to nlohmann#1697

[FHS]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#usrshareArchitectureindependentData
[thread]: marzer/tomlplusplus#165 (comment)
nlohmann pushed a commit that referenced this issue Jul 29, 2022
As nlohmann_json is a header-only library, its pkg-config and cmake
config files should be installed to `share/` (GNUInstallDirs' DATADIR),
as `share/` is the canonical directory where architecture-independent
files should be stored, while `lib/` is for architecture-dependent stuff
(see the [FHS][]).

Apart from being technically correct, installing to `share/` can help
with cross-compiling, for example in Debian-based environments. If
you're interested, I'd suggest reading this [thread][].

Related to #1697

[FHS]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#usrshareArchitectureindependentData
[thread]: marzer/tomlplusplus#165 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: bug release item: 🔨 further change solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants