Re: On Boost and modules

From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2024-04-09 13:43:26

On 09.04.24 15:14, Andrey Semashev via Boost wrote:
> On 4/9/24 15:31, Rainer Deyke via Boost wrote:
>> On 08.04.24 20:29, Robert Ramey via Boost wrote:
>>> The more I read this thread, the more it seems to me that modules are
>>> just a bad idea.  We already have shared libraries which are
>>> redistributable and that's already a hassle given all the compiler
>>> switches.  shared libraries have the same issue in that if one only
>>> want's to use one function, the whole library has to be shipped.
>>
>> This does not follow.  Shared libraries have problems, therefore modules
>> (which /solve/ many of these problems) are a bad idea?  What?
>>
>> I'm picturing a future where modules (in source code form) become /the/
>> way to distribute C++ libraries.
> 
> Your system won't run the C++ modules, someone has to compile them
> first. Build systems aren't going anywhere, as well as compiled libraries.

I'm fine with one build system.  The one I use to compile my own code. 
I'm not fine with the dozen or so build systems I currently have to use 
to build my dependencies.

Looking at my list of dependencies, I've got to deal with:
   - Autotools.
   - CMake.  Different versions thereof.
   - Meson.
   - Ninja.
   - SCons.
   - Hand-written makefiles.
   - Broken build files for all of the above, requiring manual patching.
   - Probably a bunch more I forgot about.
   - And of course Boost's own b2.

>>  Â  Advantages:
>>    - No more messing with build systems for the library author.  Just
>> ship the source code.
> 
> Shipping the source code is not new. Building libraries from source is
> also not new.

Shipping plain source that can just be dropped into source tree is far 
too rare.

>>  Â  - No more messing with library build systems for the library consumer.
> 
> Unless the consumer doesn't want to compile the dependencies all the time.

You don't recompile the dependencies "all the time".  You compile once 
per configuration and recompile when the dependency changes, same as any 
other source file.  Your build system takes care of this.

 > I'm not sure what the [below] two mean.
>>  Â  - Unified build system does not need to differentiate between user
>> files and library files.

This means I just need to deal with one build system, not one per library.

>>  Â  - Consistent macro-based configuration for all libraries, not just
>> header-only libraries

This means that there is just one way of configuring a library, by 
defining configuration macros.  No messing around with CMake variables 
or command-line arguments for configure scripts or whatever Meson or 
SCons use.

-- 
Rainer Deyke (rainerd_at_[hidden])