Closed mojca closed 1 year ago
CMakeLists.txt is deliberately withheld from the release tarballs because it doesn't work on them.
Why would it work with git checkout and not with the release? (I still need to test anyway.)
Because in the release archive all libs/<libname>/include
directories are first copied into boost/
and then deleted.
I guess this can be closed then. I tried to add the file and in fact it doesn't work.
Is there any chance to fix it at some point in the future? I.e. to make CMake code compatible with both file layouts?
The current release layout is pretty hostile to the CMake infrastructure. E.g. if you do cmake -DBOOST_INCLUDE_LIBRARIES=assert .. && cmake --install .
, this ordinarily installs only Boost.Assert and its dependencies, but with the release layout, all the library headers are dumped into boost/
and there's no way to then figure out which's which.
I'm not sure what the best way forward is, which is why I haven't tried to work towards fixing this.
I suppose, one way would be to distribute yet another set of release archives with git-style layout.
Or just leave the include directories intact instead of deleting them.
I don't like the idea of duplicating headers.
When you download an archive, you want the headers in one place or the other, but never in both.
A separate release archive for CMake would also work, I suppose.
Related: https://github.com/dear-github/dear-github/issues/214
Doesn't look likely to be fixed soon, so maybe we need to set up a Github action for boostorg/boost that uploads an archive with submodules whenever a tag is pushed?
Or maybe there's a chance, if https://github.com/git/git/pull/1359 is accepted. Looks like it's on track.
maybe we need to set up a Github action for boostorg/boost that uploads an archive with submodules whenever a tag is pushed?
Yes, that sounds good. The only tricky part is providing secrets for uploading to the storage server.
Re. GitHub and git issues, is there a problem with tar --exclude-vcs -cJf boost-X.YZ.tar.xz boost-X.YZ
? I mean, I don't think we need either of these enhancements to be able to release our archives.
Perhaps, this should be discussed with release managers on the ML?
This would automatically make the archive available for download from Github, we wouldn't need to upload it somewhere else and host it. Like the current https://github.com/boostorg/boost/releases/tag/boost-1.80.0, except not useless.
A snapshot of the git layout uploaded as a standalone release would be awesome.
Compare with a random other project like https://github.com/wxWidgets/wxWidgets/releases/tag/v3.2.1
All the files you see there have been generated "externally" and added to the release page, this wasn't auto-generated by GitHub (and thus doesn't depend on whether or not GitHub starts automatically generating the tarballs including submodules some time in the future; maybe they do, but there's no need to wait for it).
I tried to install Boost on Windows inside a GitHub action and cloning from git takes several minutes, but better yet: installing via vcpkg install boost-date-time boost-filesystem boost-program-options boost-regex boost-system
needs 7 min 30 s and choco install boost-msvc-14.3
need 11 min(!!!), for a binary install.
Any option that would speed up the build would be more than welcome.
When building C++ projects that require boost it is super easy to just use
FetchContent
to pull Boost sources in.It is however super annoying that
CMakeLists.txt
is missing from the official tarball which forces users to fetch Boost from Git directly. I would be extremely grateful if this could be fixed in time for the 1.81.0 beta.The latter introduces a number additional annoyances: it takes forever to recursively clone absolutely everything from git (fetching the tarball is much faster), CMake has a bug (or rather: missing feature) that it doesn't know how to properly cache certain things which nearly forces users into having internet connection constantl available as a hard dependency during each build, even if they have already fetched all the files etc. etc.
@pdimov