-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 15 June 2014 12:46 To: boost@lists.boost.org Subject: [boost] date_time -> serialization (Was: spirtit -> serialization)
Vicente J. Botet Escriba wrote: Le 15/06/14 12:48, Andrey Semashev a écrit :
The approach of extracting glue headers to separate submodules is not scalable. We have many other libraries using the same approach to optional dependencies.
Why? I don't see why I would depend on Serialization if I don't use it even if I use DateTime. IMHO, it is up to the client of the serialization of the DateTime types to use the DateTime.Serialization sub-module.
What others think?
I think that Vicente is right in this case. Moving serialization support to a submodule of DateTime will make the dependency report nicer _and_ it will actually be correct from the perspective of an automatic downloader. If you use DateTime, you'll get the DateTime repo, along with the serialization support, but you will not get
Serialization repo (and its dependencies) if you don't use Serialization. And
the this is
exactly as it should be, unless I'm missing something subtle.
It seems to me that this is a legitimate use of sub-sub-modules.
I've followed this thread with interest and general support, but there is one factor that doesn't seem to be 'factored-in' in. If someone is using Serialisation then isn't there a very high probability that they are also using DateTime? So having these in the same package doesn't really matter (except for the artificial level number)? Looking at the shrink-wrap users, I have a suspicion that this applies quite widely - many people will manage to pull in a big chunk of Boost. Rearranging the modules isn't going to change this much. Sub-sub-modules sound Very Evil to me. KISS applies? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830