Skip to content

Conversation

k3DW
Copy link

@k3DW k3DW commented Sep 11, 2025

Follow-up of #81

@pdimov
Copy link
Member

pdimov commented Oct 6, 2025

Let's leave BOOST_INSTALL_INCLUDE_SUBDIR alone and (always, regardless of layout) install into CMAKE_INSTALL_DATADIR/boost-1.90.0.

I'll take a look at the rest later.

@k3DW
Copy link
Author

k3DW commented Oct 6, 2025

It makes more sense to have matching installation for include/ and extra/. Using BOOST_INSTALL_INCLUDE_SUBDIR avoids that issue. For example, either we get include/boost-1_90 and share/boost-1_90, or we get simply include and share. I think they should always match.

@pdimov
Copy link
Member

pdimov commented Oct 6, 2025

No, I don't think it does. The include subdir is maintained for consistency with b2 install, new things (e.g. the CMake config files) use the -1.90.0 convention.

I don't think that dumping all the libs/libname/extra directories into /usr/share is what we want (or what the user would have wanted.) We can afford to do this for libs/libname/include only because their contents always have a boost subdirectory, usually boost/libname subdirectory, and collisions are checked by b2 headers. We don't have any established conventions for the contents of extra, or any enforcement or checks for those nonexistent conventions.

So to avoid dumping random things into /usr/share, we should install in a subdirectory, and to avoid libraries stepping over one another's toes, we probably should install into boost_libname-1.90.0, like the CMake configs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants