boostorg / release-tools

5 stars 24 forks source link

Include CMakeLists.txt in source distribution #35

Closed mojca closed 1 year ago

mojca commented 1 year ago

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

pdimov commented 1 year ago

CMakeLists.txt is deliberately withheld from the release tarballs because it doesn't work on them.

mojca commented 1 year ago

Why would it work with git checkout and not with the release? (I still need to test anyway.)

pdimov commented 1 year ago

Because in the release archive all libs/<libname>/include directories are first copied into boost/ and then deleted.

mojca commented 1 year ago

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?

pdimov commented 1 year ago

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.

Lastique commented 1 year ago

I suppose, one way would be to distribute yet another set of release archives with git-style layout.

pdimov commented 1 year ago

Or just leave the include directories intact instead of deleting them.

Lastique commented 1 year ago

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.

pdimov commented 1 year ago

A separate release archive for CMake would also work, I suppose.

pdimov commented 1 year ago

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?

pdimov commented 1 year ago

Or maybe there's a chance, if https://github.com/git/git/pull/1359 is accepted. Looks like it's on track.

Lastique commented 1 year ago

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.

Lastique commented 1 year ago

Perhaps, this should be discussed with release managers on the ML?

pdimov commented 1 year ago

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.

mojca commented 1 year ago

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.