Re: [jamboost] Re: Final target paths proposal

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-28 01:57:25

Christopher Currie wrote:

> That's not what I'm suggesting. I'm suggesting that main targets ALWAYS
> include their name in the path, regardless of potential conflict. 

Ah.. that's precisely my original proposal -- to adopt the scheme currently 
used by V1.

> I
> haven't looked into the code, so this may not be as simple a change as I
> make it sound.

The only problem is the one I described with need to add <main-target> 
properties.

> > Consider:
> >
> > exe a : a.cpp ;
> > exe b : a.cpp ;
> >
> > Current V2 detects that both a.o have the same properties, so a.o is
> > shared between main targets. The only way to prevent this would be
> > to add some property, which is different for "a" and "b" main target.
> > For example, "a" can have <main-target>a property and "b" can have
> > "<main-target>b" property.
>
> This seems more convoluted than I had intended; I thought it would be
> more a matter of setting the grist on the object file differently, so it
> would result in a different target. But if it would mean creating a new
> feature, then I can see why you'd be reluctant.

The reason why it's harder is that V2 don't directly generate jam targets. It 
first generates "virtual-targets" and spends some effort trying to make sure 
that there are no two virtual targets with the same name and the same 
properties. So, to put a.o from two different main targets in two different 
directories, you'd need different property.

> >> Some compilers, such as the much bemoaned Sun C++ compiler,
> >> actually operate more reliably when this is the case, although this
> >> is a secondary concern (except for we unfortunates without an
> >> alternative).
> >
> > Could you explain what's the problem with CC in this case?
>
> Sun CC creates a SunWS_cache directory in every directory where it
> builds a target. This directory contains the "template repository" where
> it stores the compiled object code for every template instantiation it
> builds while working in that directory. The problem is that if two
> disparate targets are built in the same directory, sometimes wierd ODR
>
> violations creep up. From the Sun C++ Users Guide (Forte Developer 7):
> > Templates that are within a repository must not violate the
> > one-definition rule of the ISO C++ standard. That is, a template must
> > have the same source in all uses of the template. Violating this
> > rule produces undefined behavior.
> >
> > The simplest, though most conservative, way to ensure the rule is not
> > violated is to build only one program or library within any one
> > directory. Two unrelated programs might use the same type name or
> > external name to mean different things. If the programs share a
> > template repository, template definitions could conflict, thus
> > yielding unpredictable results.

Oh... badness!

> I've generally seen very odd behavior resulting from Sun's poor template
> repository management, resulting in wierd recompilations of code at link
> time because the linker though that a template instantiation was "out of
> date," or link failures because it couldn't find the proper
> instantiation of a template.
>
> Annoying as those troubles are, however, I sympathise with you as build
> system developer and don't feel that Sun's problems alone should
> influence how build trees are managed, especially considering that Sun
> CC 5.4 (Sun ONE Studio 8) uses a completely different method of managing
> templates that eliminates the whole problem. If only my company would
> upgrade...

And I certainly sympathise with you as user of specific compiler that can't be 
switched right away. I think you problem can be still solved, even if no 
other user request the directory layout that you'd like. For example, you or 
I can make a patch to change directory layout and you can use patched 
Boost.Build for development.

> I simply thought that the work involved maintaining this logic would not
> outway the expense of building the object file twice. 

Sorry, what's "outway"? http://www.m-w.com did not helped me with this 
word ;-)

> > 1. Use the scheme I've proposed.
> > 2. If that causes issues in practice, as opposed to theory, change the
> > scheme to add <main-target> properties for main targets. This will
> > automatically place objects from different main targets into different
> > directories.
>
> Having beat the dead horse enough, I'm fine with this proposal, I just
> wanted to air my concerns. It is you, after all, who are doing most of
> the work keeping BBv2 alive, for which we are all profoundly thankful.

Thanks. I'm about to implement the change right away. Hopefully we'll 
accomodate your needs, too.

- Volodya