Missing libraries requiring compilation

[anarthal]

Which documentation does this apply to? User's Guide

The page user-guide/header-organization-compilation.html#_required_compiled_binaries lists all libraries allowing compilation, but it looks like some of them are missing.

There is an option to b2, ./b2 --show-libraries, that is worth mentioning in this page. It will show you which libraries can be built (useful to find out which --with-<lib> you can do. Here is the list I got from 1.82 in my Linux:

    - atomic
    - chrono
    - container
    - context
    - contract
    - coroutine
    - date_time
    - exception
    - fiber
    - filesystem
    - graph
    - graph_parallel
    - headers
    - iostreams
    - json
    - locale
    - log
    - math
    - mpi
    - nowide
    - program_options
    - python
    - random
    - regex
    - serialization
    - stacktrace
    - system
    - test
    - thread
    - timer
    - type_erasure
    - url
    - wave

[alandefreitas]

I've noticed this for a while in the legacy content. I don't know who is maintaining this list. Even with b2 --show-libraries, someone needs to remember to do it.

The old guide was actually two guides: one about header-only libraries and another about compiled libraries, which includes the list. In general, I don't think this list should even exist. Or at least this should be a goal. For historical reasons, header-only libraries being the default were considered a nice thing. Nowadays, new libraries are not always header-only, many libraries of interest (not absorbed by the STL) are not header-only, and being header-only by default is not considered something nice to have (it's usually seen just as slow compilation because integrating and linking targets in no longer a huge problem in 2023).

I believe the new guide should stop being two guides. It should be a single guide that tells you how to install boost with all the header-only and compiled libraries. The user should see the libraries as targets that will work regardless of how they are linked.

In a more advanced section, we could later list options, including options to remove libraries for users who don't want the whole thing. At this point, b2 --show-libraries could be presented. If the list is also going to be presented, which I don't think it should, the output of b2 --show-libraries should be an antora partial and this partial would be automatically generated.

[PeterTurcan]

I am not seeing the "headers" library in the 1_82 list: Boost Libraries - 1.82.0 https://www.boost.org/doc/libs/1_82_0/libs/libraries.htm

Is it missing from this list, or is there something special about it?

thanks

On Sun, Apr 30, 2023 at 10:12 AM Alan de Freitas @.***> wrote:

I've noticed this for a while in the legacy content. I don't know who is maintaining this list. Even with b2 --show-libraries, someone needs to remember to do it.

The old guide was actually two guides: one about header-only libraries and another about compiled libraries, which includes the list. In general, I don't think this list should even exist. Or at least this should be a goal. For historical reasons, header-only libraries being the default were considered a nice thing. Nowadays, new libraries are not always header-only, many libraries of interest (not absorbed by the STL) are not header-only, and being header-only by default is not considered something nice to have (it's usually seen just as slow compilation because integrating and linking targets in no longer a huge problem in 2023).

I believe the new guide should stop being two guides. It should be a single guide that tells you how to install boost with all the header-only and compiled libraries. The user should see the libraries as targets that will work regardless of how they are linked.

In a more advanced section, we could later list options, including options to remove libraries for users who don't want the whole thing. At this point, b2 --show-libraries could be presented. If the list is also going to be presented, which I don't think it should, the output of b2 --show-libraries should be an antora partial and this partial would be automatically generated.

— Reply to this email directly, view it on GitHub https://github.com/cppalliance/site-docs/issues/32#issuecomment-1529082987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIBS2JPHHVXF5A242MASITXD2MQBANCNFSM6AAAAAAXQHTCTE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[alandefreitas]

I am not seeing the "headers" library in the 1_82 list: Boost Libraries -

b2 --show-libraries will show all libraries: be it an interface library or a compiled library. headers is special in which it's not a compiled library. It's sort of an interface library representing all other libraries. So headers is probably manually removed by whoever transcribed that list.

[PeterTurcan]

@alandefreitas Creating an antora partial with a list of compiled binaries automatically sounds like a reasonable way to proceed here. I do think the list of libs that require binaries should be listed rather than asking the user to run a tool. Perhaps the partial could be built by updating the current build system? if so, who would I ask to add the line(s) to our build scripts to create this?

[alandefreitas]

updating the current build system

What do you mean by that? The CI scripts? Or build.sh?

who would I ask to add the line(s) to our build scripts to create this?

I think updating build.sh is relatively easy. The problem is coming up with the design.

build.sh and other scripts make no reference to boost. That means the boost source and b2 are now a dependency of build.sh. Then we have to decide where it's expected to be, etc... Then we have to update CI to generate that... Then we might have problems with Antora, which expects the data to be available in (pushed to) all branches it uses to generate the versions. Vinnie had an idea for a collector antora extension that would generate pages but we don't have that yet.

So there are a lot of decisions involved and each decision requires some experimentation. I would do that incrementally instead: whatever scripts are used to generate these partials are initially isolated in some scripts folder. These would probably be some python scripts because it's easier to maintain although I have nothing against JS. Then we run these scripts from time to time to regenerate the pages and just keep it like that for a while. Once this is stable, and we have good conventions for what the scripts expect, etc... then we move to the next design decision, which might be updating it from CI or including it in build.sh.