Re: Problems with header-only lib

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-15 12:22:13

Vladimir Prus <ghost_at_[hidden]> writes:

>> Of course, this part is still a problem, and really needs to be
>> properly resolved.
>
> It's not "architectural problem", if by architecture you mean code
> design. 

No, I mean system design. The fact that we have no way to represent
this sort of requirement is a problem in the design of the system. We
didn't anticipate the need for it.

> It's more like specification issue -- I don't know what's the right
> behaviour would be.

Clearly in this *particular* case the right behavior is the one that
propagates an asynch exception requirement to everything.

> In the example:
>
> run copy.cpp /boost/test//minimal some_other_lib ;
>
> we first pass all build properties to dependencies. Then we collect usage
> requirements from dependencies and build copy.cpp. If dependencies return
> only free features in usage requirements, it's fine, because free features are 
> not propagated anyway.
>
> But with non-free features -- should we add usage-requirements from 'minimal' 
> to properties used for building 'some_other_lib'? Or add usage-requirements
> from 'some_other_lib' to build properties for 'minimal'. 

If this example is any guide, we should add all *propagated*
usage-requirements to the properties used for building all other
targets in the same dependency graph.

We may find examples that indicate we need different "propagation
strengths," so that some features are only propagated to dependents
and not to siblings in the graph, but in absence of such examples, we
have to go with the above behavior.

> Or add usage-requirements?

I don't understand that sentence.

> What if adding usage requirements of 'some_other_lib' to build
> properties for 'minimal' change the selected alternative of
> 'minimal' and so changes the usage requirements from 'minimal'?

The "right thing to do" is to keep resolving things until the selected
alternatives stabilize or you detect that the process would cycle
forever.

However, until that can be done you could make that scenario an error,
or if you really don't have time, make it unsupported with no
diagnostic required.

The most important thing is to support the use cases we know are
needed. Making a system that can conceivably work for any use case is
a lower priority.

> In order to allow propagating non-free properties in usage
> reqirements to other dependencies we need a very detailed spec
> saying how it should work, and so far I have no ideas what's the
> right semantic is.

I don't think it would be too hard to fill in the details on the
"right thing to do" described above for someone who understood the
current algorithm. Unfortunately, I don't. The last time I reviewed
the documentation I had lots of questions in this area. I have not
entered my editorial comments for that section into the documentation
source yet, but I've just been trying to stay ahead of your processing
of those comments. Unless I'm mistaken, you haven't come close to
catching up with what I've already done. So I think we're at a bit of
an impasse.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com