Boost logo

Boost :

Subject: Re: [boost] [type_traits] Rewrite and dependency free version
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-02-03 02:10:57

Le 03/02/15 01:16, Rene Rivera a écrit :
> I think the above is what many other people are suggesting already.
> Unless I've misinterpreted the requests. With that in mind I suggested
> this <> as a library structure (suggestion
> #2).
Adding here the second option
option is to have each library have to explicit sublibs/parts. "core" and
"full". Structure would be:

   * libs/<lib>/core/(build, doc, include, meta, test)
   * libs/<lib>/full/(build, doc, include, meta, test)

Note, both core and full would be in the same git repo to make life easier
for library authors and users that visit a library git repo on github. As
it's only one place for everything for that one library.

As a user, release manager, testing manager, and library author this would
be easy to understand and manage than the current "some random set of
libraries have core or not and in different places".

IMO, this is a minor variant of what we already have. Consider
libs/<lib> to play the role of libs/<lib>/full. Your structure is more
explicit, but I don't think we need to go so far as the submodule
information is on the meta/libraries.json file. This doesn't mean that a
library can not do that.

I find very useful to split a library into submodules.
* It helps to limit the dependencies as more fine grained,
* it makes easier to move a submodule from one github repository to
another as the structure of a submodule is the same as the structure of
a library (a submodule it self). This could be useful if we want to
transfer the maintenance of the submodule.

Robert, your bridge proposal could just consist in creating

   libs/serialization/bridge/(build, doc, include, meta, test)

and adding the submodule on the libs/serialization/meta/libraries.json file.


Boost list run by bdawes at, gregod at, cpdaniel at, john at