CMakeLists.txt in release zips?

[eliasdaler]

Hello, I've tried using FetchContent CMake module and this doesn't work as well as I expected. The problem is that after I download and unpack the zip, there's no CMakeLists.txt file, so I can't just get nlohmann_json target and link with it.

If you take a look at libraries like fmt, they include CMakeLists.txt in their releases, which makes fetching zips and then getting targets at configure step quite easy.

So, can we have CMake related files included in zips for future releases?

[eliasdaler]

On the other hand, having license file and some tests might also be useful. (Just not a lot of MBs ones)

So, a sort of trimmed down sources.tar.gz version of this repo.

But this is just "nice to have" and arguable. CMake files on the other hand are more important to have.

[nlohmann]

What's wrong with using the zip archive of the sources?

[eliasdaler]

Its size - 109 mb. It takes a while to download at slower connections and makes a built folder quite large after it unpacks (unpacking is also done at configuration time and takes some time)

It's the most significant bottleneck for my project right now. Just includes are several kb. Downloading them is really fast, but not having CMake makes them not configurable via CMake easily.

[eliasdaler]

By the way, for those who want to use FetchContent now, this works fine:

include(ExternalProject)

FetchContent_Declare(nlohmann_json
  URL https://github.com/nlohmann/json/releases/download/v3.1.2/include.zip
)

FetchContent_Populate(nlohmann_json)

# temporal, until releases don't include CMakeLists.txt! After, just use:
# add_subdirectory(${nlohmann_json_SOURCE_DIR} ${nlohmann_json_BINARY_DIR})
add_library(nlohmann_json INTERFACE)
target_include_directories(nlohmann_json INTERFACE ${nlohmann_json_SOURCE_DIR})

# and now you can do this:
# target_link_libraries(your_target nlohmann_json)

[nlohmann]

We‘re already supporting a lot of package managers, so I am not really willing to spend more efforts in adding more files to the release.

[OvermindDL1]

@nlohmann That's not a manager of any form, without a CMakeLists.txt in the zip that means add_subdirectory and so forth can't be used, have to link manually instead.

[eliasdaler]

Agreed. The only thing that needs to be added is CMakeLists.txt and (possibly) cmake/config.cmake.in

CMake is not only used for building the library itself, it's also a means to easily use it, as can be seen from my example. And when you have this, you can support a lot of package managers. And this is with several kb zip instead of 100 mb zip.

[nlohmann]

I already do support a lot of package managers, and up to now this is the first time someone wants the CMakeLists.txt in the release.

[theodelrieu]

It could be easier if someone were to publish the library with CPack? I never used it but you could use it with CMake directly too

[OvermindDL1]

I already do support a lot of package managers, and up to now this is the first time someone wants the CMakeLists.txt in the release.

Well I grab it either via hunter or just a straight git clone, so I get a cmake file regardless. ^.^

It could be easier if someone were to publish the library with CPack? I never used it but you could use it with CMake directly too

Oh wait, cpack is not already being used to make the release? What is it a shell script or something instead? That doesn't really generate the config file properly...

[nlohmann]

I shall try cpack.

[eliasdaler]

I already do support a lot of package managers, and up to now this is the first time someone wants the CMakeLists.txt in the release.

They are supported if the user clones the whole repo, right? Up until now, I've manually cloned the repo, removed everything except includes and cmake files and then stored the stripped repo on disk.

If there was a way to clone only some files from a repo, maybe I wouldn't ask for CMake inside the release zips.

It could be easier if someone were to publish the library with CPack? I never used it but you could use it with CMake directly too

While CPack might automate the process, it still depends on what goes in the zip. And if CPack config is in some cmake file and that file won't be present in one of stripped release zips, this would not solve the problem of not having to clone the whole repo.

[nlohmann]

Alright, CPack is not really helpful if applied to the current package. I could try to exclude files from the package, but I think this is not really helping. Question is: does the current CMakeLists.txt would really help if added to the release? Or would we rather need a stripped down version? If so, we may think of writing a script that puts only the sources and that stripped-down CMakeLists.txt in a folder and run make package_sources on in and use that archive for the release. This would be self-contained and we would not need to attach other files to the release. Right?

[eliasdaler]

Here's some analysis. When I download repo as zip using GitHub, I get 109 MB zip. it's 240 MB when unpacked.

After that I've removed "jeopardy" benchmark and data folders for two tests: "json_nlohmann_tests" and "regression".

After that, I've got 15.3 MB left. It's 7.34 MB when zipped.

So, I think we can have a stripped release version with these tests left out. The user should either clone the whole repo to run them or there should be some script which will download the data if the user specifies that these tests should be built (via some BUILD_EXTRA_TESTS option or something)