[modularization] spirtit -> serialization

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[modularization] spirtit -> serialization

Vicente Botet

Hi,

comments about this dependency:


      |<boost/serialization/vector.hpp>|

  * from |<boost/spirit/home/support/detail/lexer/serialise.hpp>|

It seems that this file is not used

|boost/spirit/home/support/detail/lexer/serialise.hpp

Could this file be removed or moves to examples?

Best,
Vicente
|

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Stephen Kelly-2
Vicente J. Botet Escriba wrote:

>
> Hi,
>
> comments about this dependency:
>
>
>       |<boost/serialization/vector.hpp>|
>
>   * from |<boost/spirit/home/support/detail/lexer/serialise.hpp>|
>
> It seems that this file is not used
>
> |boost/spirit/home/support/detail/lexer/serialise.hpp
>
> Could this file be removed or moves to examples?

I think if the intent is to remove circular dependencies, you should see if
you can split the archive parts of the serialization out and make only that
part depend on spirit.

Thanks,

Steve.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Vicente Botet
Le 13/06/14 18:41, Stephen Kelly a écrit :

> Vicente J. Botet Escriba wrote:
>
>> Hi,
>>
>> comments about this dependency:
>>
>>
>>        |<boost/serialization/vector.hpp>|
>>
>>    * from |<boost/spirit/home/support/detail/lexer/serialise.hpp>|
>>
>> It seems that this file is not used
>>
>> |boost/spirit/home/support/detail/lexer/serialise.hpp
>>
>> Could this file be removed or moves to examples?
> I think if the intent is to remove circular dependencies, you should see if
> you can split the archive parts of the serialization out and make only that
> part depend on spirit.
>
>
This corresponds to the opposite dependency.
My first goal is to break the cycles.

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Stephen Kelly-2
Vicente J. Botet Escriba wrote:

> Le 13/06/14 18:41, Stephen Kelly a écrit :
>> I think if the intent is to remove circular dependencies, you should see
>> if you can split the archive parts of the serialization out and make only
>> that part depend on spirit.
>>
>>
> This corresponds to the opposite dependency.
> My first goal is to break the cycles.

I am aware of that.

That is why I wrote:

 > I think if the intent is to remove circular dependencies [...]

Here is a graph which assumes the range->algorithm edge removal and treats
math<->lexical_cast as an incidental module:

 http://www.steveire.com/boost/2014_jun_before-spirit-serialization.png

And after removing the serialization->spirit edge:

 http://www.steveire.com/boost/2014_jun_after-spirit-serialization.png

Thanks,

Steve.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Vicente Botet
Le 14/06/14 08:56, Stephen Kelly a écrit :

> Vicente J. Botet Escriba wrote:
>
>> Le 13/06/14 18:41, Stephen Kelly a écrit :
>>> I think if the intent is to remove circular dependencies, you should see
>>> if you can split the archive parts of the serialization out and make only
>>> that part depend on spirit.
>>>
>>>
>> This corresponds to the opposite dependency.
>> My first goal is to break the cycles.
> I am aware of that.
>
> That is why I wrote:
>
>   > I think if the intent is to remove circular dependencies [...]
>
> Here is a graph which assumes the range->algorithm edge removal and treats
> math<->lexical_cast as an incidental module:
>
>   http://www.steveire.com/boost/2014_jun_before-spirit-serialization.png
>
> And after removing the serialization->spirit edge:
>
>   http://www.steveire.com/boost/2014_jun_after-spirit-serialization.png
>
>
The local_function <-> scoped_exit cycle will be taken in account by
Lorenzo.

I don't think the serialization -> spirit dependency must be removed
forcedly. As I said in another post the opposite seems unuseful as the
file is not used.

We can manage with the graph cycle by extracting the following submodules

bimap.property_map -> bimap property_map
property_map.parallel ->property_map mpi

and grouping graph and disjoint_set.

In the same way extracting the serialization part from date_time to a
submodule helps to break the date_time. I would say that we should do
the the same for each module that depends on serialization, create a
submodule

module.serialization -> module serialization

The dependencies to tr1 should be removed and replaced by the underlying
Boost libraries.

Another dependency that can be broken is chrono -> interprocess buy
adding a chrono.io submodule.

I'll create the chrono.io submodule myself.

Best,
Vicente




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Stephen Kelly-2
Vicente J. Botet Escriba wrote:

>> Here is a graph which assumes the range->algorithm edge removal and
>> treats math<->lexical_cast as an incidental module:
>>
>>http://www.steveire.com/boost/2014_jun_before-spirit-serialization.png
>>
>> And after removing the serialization->spirit edge:
>>
>>http://www.steveire.com/boost/2014_jun_after-spirit-serialization.png
>>
>
> I don't think the serialization -> spirit dependency must be removed
> forcedly. As I said in another post the opposite seems unuseful as the
> file is not used.

Let's try to keep the discussion to serialization and spirit. The other
things you note are off topic in this thread. Try to look only at the
interaction of serialization and spirit.

Look at

 http://www.steveire.com/boost/2014_jun_before-spirit-serialization.png

If you remove spirit->serialization, the cycle

 spirit -> pool -> thread -> date_time -> serialization [ -> spirit ]

still exists.

First question:

  Do you see that?

Thanks,

Steve.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Vicente Botet
In reply to this post by Stephen Kelly-2
Le 13/06/14 18:41, Stephen Kelly a écrit :

> Vicente J. Botet Escriba wrote:
>
>> Hi,
>>
>> comments about this dependency:
>>
>>
>>        |<boost/serialization/vector.hpp>|
>>
>>    * from |<boost/spirit/home/support/detail/lexer/serialise.hpp>|
>>
>> It seems that this file is not used
>>
>> |boost/spirit/home/support/detail/lexer/serialise.hpp
>>
>> Could this file be removed or moves to examples?
> I think if the intent is to remove circular dependencies, you should see if
> you can split the archive parts of the serialization out and make only that
> part depend on spirit.
>
>
Sorry, I didn't understood correctly your sentence. Now I agree with
you, spliting serialization and archive would help a lot.

I'll start a new wiki page with the dependencies to break.

Best,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Stephen Kelly-2
Vicente J. Botet Escriba wrote:

>> I think if the intent is to remove circular dependencies, you should see
>> if you can split the archive parts of the serialization out and make only
>> that part depend on spirit.
>
> Sorry, I didn't understood correctly your sentence. Now I agree with
> you, spliting serialization and archive would help a lot.

Great! In the future please don't be so quick to assume I don't know what
I'm talking about and we can avoid wasting mails :).

Once the range->algorithm and serialization->spirit edges are removed,
another phase of this dependency work can begin. Those edges are the two
most important ones from a cycles point of view.

Thanks for all of your work,

Steve.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Vicente Botet
In reply to this post by Stephen Kelly-2
Le 14/06/14 18:34, Stephen Kelly a écrit :

> Vicente J. Botet Escriba wrote:
>
>>> Here is a graph which assumes the range->algorithm edge removal and
>>> treats math<->lexical_cast as an incidental module:
>>>
>>> http://www.steveire.com/boost/2014_jun_before-spirit-serialization.png
>>>
>>> And after removing the serialization->spirit edge:
>>>
>>> http://www.steveire.com/boost/2014_jun_after-spirit-serialization.png
>>>
>> I don't think the serialization -> spirit dependency must be removed
>> forcedly. As I said in another post the opposite seems unuseful as the
>> file is not used.
> Let's try to keep the discussion to serialization and spirit. The other
> things you note are off topic in this thread. Try to look only at the
> interaction of serialization and spirit.
You could as well start a new thread for this dependency ;-)

> Look at
>
>   http://www.steveire.com/boost/2014_jun_before-spirit-serialization.png
>
> If you remove spirit->serialization, the cycle
>
>   spirit -> pool -> thread -> date_time -> serialization [ -> spirit ]
>
> still exists.
>
> First question:
>
>    Do you see that?
>
>
Yes, and I propose to create a date_time.serialization submodule that
breaks the date_time -> serialization dependency.

date_time.serialization -> date_time serialization

Best,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Vicente Botet
In reply to this post by Vicente Botet
Le 14/06/14 18:44, Vicente J. Botet Escriba a écrit :

> Le 13/06/14 18:41, Stephen Kelly a écrit :
>> Vicente J. Botet Escriba wrote:
>>
>>> Hi,
>>>
>>> comments about this dependency:
>>>
>>>
>>>        |<boost/serialization/vector.hpp>|
>>>
>>>    * from |<boost/spirit/home/support/detail/lexer/serialise.hpp>|
>>>
>>> It seems that this file is not used
>>>
>>> |boost/spirit/home/support/detail/lexer/serialise.hpp
>>>
>>> Could this file be removed or moves to examples?
>> I think if the intent is to remove circular dependencies, you should
>> see if
>> you can split the archive parts of the serialization out and make
>> only that
>> part depend on spirit.
>>
>>
> Sorry, I didn't understood correctly your sentence. Now I agree with
> you, spliting serialization and archive would help a lot.
>
> I'll start a new wiki page with the dependencies to break.
>
Done

https://svn.boost.org/trac/boost/wiki/ModuleDepednecies

Please, be free to update this page with any suggestion that could help
to reduce the dependencies.

Best,
Vicente


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Andrey Semashev-2
In reply to this post by Vicente Botet
On Sunday 15 June 2014 12:13:08 Vicente J. Botet Escriba wrote:

> Le 14/06/14 18:34, Stephen Kelly a écrit :
> > Vicente J. Botet Escriba wrote:
> >>> Here is a graph which assumes the range->algorithm edge removal and
> >>> treats math<->lexical_cast as an incidental module:
> >>>
> >>> http://www.steveire.com/boost/2014_jun_before-spirit-serialization.png
> >>>
> >>> And after removing the serialization->spirit edge:
> >>>
> >>> http://www.steveire.com/boost/2014_jun_after-spirit-serialization.png
> >>
> >> I don't think the serialization -> spirit dependency must be removed
> >> forcedly. As I said in another post the opposite seems unuseful as the
> >> file is not used.
> >
> > Let's try to keep the discussion to serialization and spirit. The other
> > things you note are off topic in this thread. Try to look only at the
> > interaction of serialization and spirit.
>
> You could as well start a new thread for this dependency ;-)
>
> > Look at
> >
> >   http://www.steveire.com/boost/2014_jun_before-spirit-serialization.png
> >
> > If you remove spirit->serialization, the cycle
> >
> >   spirit -> pool -> thread -> date_time -> serialization [ -> spirit ]
> >
> > still exists.
> >
> > First question:
> >    Do you see that?
>
> Yes, and I propose to create a date_time.serialization submodule that
> breaks the date_time -> serialization dependency.
>
> date_time.serialization -> date_time serialization

The approach of extracting glue headers to separate submodules is not
scalable. We have many other libraries using the same approach to optional
dependencies.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

John Maddock-3
>> Yes, and I propose to create a date_time.serialization submodule that
>> breaks the date_time -> serialization dependency.
>>
>> date_time.serialization -> date_time serialization
>
> The approach of extracting glue headers to separate submodules is not
> scalable. We have many other libraries using the same approach to optional
> dependencies.

+1, it seems frankly bonkers to extract single headers to new modules
just because it makes a dependency graph look better.

IMO we need a better way of looking at dependencies, perhaps by marking
up glue headers as optional.

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Vicente Botet
In reply to this post by Andrey Semashev-2
Le 15/06/14 12:48, Andrey Semashev a écrit :

> On Sunday 15 June 2014 12:13:08 Vicente J. Botet Escriba wrote:
>> Le 14/06/14 18:34, Stephen Kelly a écrit :
>>> Vicente J. Botet Escriba wrote:
>>>
>> Yes, and I propose to create a date_time.serialization submodule that
>> breaks the date_time -> serialization dependency.
>>
>> date_time.serialization -> date_time serialization
> 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?

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Andrey Semashev-2
On Sunday 15 June 2014 13:26:52 Vicente J. Botet Escriba wrote:

> Le 15/06/14 12:48, Andrey Semashev a écrit :
> > On Sunday 15 June 2014 12:13:08 Vicente J. Botet Escriba wrote:
> >> Le 14/06/14 18:34, Stephen Kelly a écrit :
> >>> Vicente J. Botet Escriba wrote:
> >> Yes, and I propose to create a date_time.serialization submodule that
> >> breaks the date_time -> serialization dependency.
> >>
> >> date_time.serialization -> date_time serialization
> >
> > 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?

Because it creates lots of tiny submodules, which creates maintainability and
usability problems.

> 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.

You are right to desire not depending on Serialization if you don't use it.
But this should not be achieved with submodules, IMHO.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

date_time -> serialization (Was: spirtit -> serialization)

Peter Dimov-2
In reply to this post by Vicente Botet
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 the Serialization repo (and its dependencies)
if you don't use Serialization. And 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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Vicente Botet
In reply to this post by Andrey Semashev-2
Le 15/06/14 13:40, Andrey Semashev a écrit :

> On Sunday 15 June 2014 13:26:52 Vicente J. Botet Escriba wrote:
>> Le 15/06/14 12:48, Andrey Semashev a écrit :
>>> On Sunday 15 June 2014 12:13:08 Vicente J. Botet Escriba wrote:
>>>> Le 14/06/14 18:34, Stephen Kelly a écrit :
>>>>> Vicente J. Botet Escriba wrote:
>>>> Yes, and I propose to create a date_time.serialization submodule that
>>>> breaks the date_time -> serialization dependency.
>>>>
>>>> date_time.serialization -> date_time serialization
>>> 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?
> Because it creates lots of tiny submodules, which creates maintainability and
> usability problems.
>
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.
> You are right to desire not depending on Serialization if you don't use it.
> But this should not be achieved with submodules, IMHO.
>
I'm open to discuss any alternative solving the issue.

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Peter Dimov-2
In reply to this post by John Maddock-3
John Maddock wrote:
> IMO we need a better way of looking at dependencies, perhaps by marking up
> glue headers as optional.

This approach causes difficulties down the road.

module X
    X.hpp

module Y
    Y1.hpp
    Y2.hpp (optional) includes X.hpp

module Z
    Z.hpp includes Y2.hpp

Does Z depend, indirectly, on X? If your answer is yes, and it must be,
remember that Y does not depend on X, so the secondary dependencies are no
longer the transitive closure of the primary dependencies.

The tool can be made to figure these things out, but to do so, it will need
to create virtual submodules, one per each optional header.

Either that, or scrap the whole module-level dependency approach and start
tracking individual headers.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Bjørn Roald
In reply to this post by Andrey Semashev-2
On 06/15/2014 01:40 PM, Andrey Semashev wrote:

> On Sunday 15 June 2014 13:26:52 Vicente J. Botet Escriba wrote:
>> Le 15/06/14 12:48, Andrey Semashev a écrit :
>>> On Sunday 15 June 2014 12:13:08 Vicente J. Botet Escriba wrote:
>>>> Le 14/06/14 18:34, Stephen Kelly a écrit :
>>>>> Vicente J. Botet Escriba wrote:
>>>> Yes, and I propose to create a date_time.serialization submodule that
>>>> breaks the date_time -> serialization dependency.
>>>>
>>>> date_time.serialization -> date_time serialization
>>>
>>> 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?
>
> Because it creates lots of tiny submodules, which creates maintainability and
> usability problems.

Optional files with additional dependencies need to be considered as
independent nodes in the dependency graph, and thus allow us to
understand how to remove undesired dependencies and potential for
cycles. If that is agreed, then the rest is a question of how to achieve
all that with tools.  For the proposed

date_time.serialization -> date_time serialization

building, deploying and using data_time no longer require serialization,
unless you actually are using date_time.serialization in your source
code at least.  The fact that the source comes along in the date_time
git repository is not a concern as long as it is reasonably inexpensive.

>> 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.
>
> You are right to desire not depending on Serialization if you don't use it.
> But this should not be achieved with submodules, IMHO.

Having these optional files in separate sub-module directories within a
library modules git repository, is just part of one potential solution.
  There may be other ways, do you have anything else in mind that scales
better?

Using the term module, or sub-module, about nodes in the dependency
graph make sense as what I think we attempt is modularization.  However
the term sub-module is somewhat misleading as they conceptually are just
as much independent modules as the top level git repository (Library)
module.  But I guess a sort of maintenance ownership is reflected by a
module being a sub-module.

Sub-modules such as optional headers could also be, "as-is", files more
embedded into the "parent" module file structure .  However that may
make it harder for tools to deal with the dependencies.

--
Bjørn

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Andrey Semashev-2
In reply to this post by Vicente Botet
On Sunday 15 June 2014 13:49:20 Vicente J. Botet Escriba wrote:

> Le 15/06/14 13:40, Andrey Semashev a écrit :
> > On Sunday 15 June 2014 13:26:52 Vicente J. Botet Escriba wrote:
> >> Le 15/06/14 12:48, Andrey Semashev a écrit :
> >>> On Sunday 15 June 2014 12:13:08 Vicente J. Botet Escriba wrote:
> >>>> Le 14/06/14 18:34, Stephen Kelly a écrit :
> >>>>> Vicente J. Botet Escriba wrote:
> >>>> Yes, and I propose to create a date_time.serialization submodule that
> >>>> breaks the date_time -> serialization dependency.
> >>>>
> >>>> date_time.serialization -> date_time serialization
> >>>
> >>> 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?
> >
> > Because it creates lots of tiny submodules, which creates maintainability
> > and usability problems.
>
> Why?

What you mean why? Submodules are a constant pain to deal with. They don't
allow the complete history of the library, they don't allow synchronized
operations on them (e.g. do changes to multiple submodules in a single
commit/push), adding or removing them requires privileges. In Log I have at
least 6 glue headers, I don't want to deal with 7 different repos if they are
extracted.

> >> 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.
> >
> > You are right to desire not depending on Serialization if you don't use
> > it.
> > But this should not be achieved with submodules, IMHO.
>
> I'm open to discuss any alternative solving the issue.

I think there was a proposal not long ago to track dependencies based on
headers, pretty much like boostdep does. Then we only need to mark the
optional headers in some metadata files and there you go.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [modularization] spirtit -> serialization

Andrey Semashev-2
In reply to this post by Peter Dimov-2
On Sunday 15 June 2014 15:13:55 Peter Dimov wrote:

> John Maddock wrote:
> > IMO we need a better way of looking at dependencies, perhaps by marking up
> > glue headers as optional.
>
> This approach causes difficulties down the road.
>
> module X
>     X.hpp
>
> module Y
>     Y1.hpp
>     Y2.hpp (optional) includes X.hpp
>
> module Z
>     Z.hpp includes Y2.hpp
>
> Does Z depend, indirectly, on X?

Yes, how could it be otherwise.

> If your answer is yes, and it must be,
> remember that Y does not depend on X, so the secondary dependencies are no
> longer the transitive closure of the primary dependencies.

It's not the question of Y depending on X anymore. If Y is header-only, it's a
question of Y2.hpp (from Y) depending on X.hpp (from X).

If Y is not header-only, the dependencies should include all dependencies of
the compiled part. Arguably, Y2.hpp may not require the compiled part, but
that case could also be handled by a metadata flag.

> The tool can be made to figure these things out, but to do so, it will need
> to create virtual submodules, one per each optional header.
>
> Either that, or scrap the whole module-level dependency approach and start
> tracking individual headers.

I'm for tracking headers. Submodules just impose too much difficulties to use
them on header level. Maintaining libraries should be fun.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123