Re: Final target paths proposal

From: Christopher Currie (Christopher_at_[hidden])
Date: 2003-10-27 14:01:12

> There's some difficulty. The conflict only exists when and object is
> used to two different main targets. To detect if this is the case, 
> and adjust target paths, one need to find target paths of all 
> targets, which is not trivially doable in current code.
> 
> Now, when each target is assigned a path name, we check if there's 
> another target with the same path name. If so, it's a conflict, and 
> an error is reported. But it would be really hard to go back to 
> previous target and change its path.

That's not what I'm suggesting. I'm suggesting that main targets ALWAYS
include their name in the path, regardless of potential conflict. I 
haven't looked into the code, so this may not be as simple a change as I 
make it sound.

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

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

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

>> obj a : a.cpp ;
>> exe b : b.cpp d.cpp a ;
>> exe c : c.cpp d.cpp a ;
>> 
>> ... which would produce:
>> 
>> bin/a/.../a.o
>> bin/b/.../b.o
>> bin/b/.../d.o
>> bin/b/.../b
>> bin/c/.../c.o
>> bin/c/.../d.o
>> bin/c/.../c
>> 
>> The results reflect the intent: the exe depends on the source, not
>> the object. The fact that the object exists is secondary; the 
>> results would be equally correct if d.cpp were passed to the link 
>> line, assuming you don't use a standalone linker (although it would
>> be less efficient in the long run, of course).
> 
> 
> You know, I can use your example to prove completely different thing.
> If object files are secondary, then I can avoid storing them in 
> filesystem at all. For example, I can store them in database, using 
> project/name/properties as a key. And in that case, sharing of object
> files would be a natural solution.

True, but the problem remains that the build system has the task of 
making sure that the applications WANT to, or OUGHT to, share the object 
files.

My argument is not that the object files are secondary, it's that the 
user in this (admittedly contrived) case specifed source files. This 
puts the burden on the build system to determine whether any object 
files you may build from those sources (as an optimization independant 
of the intent of the user) would actually be identical.

I simply thought that the work involved maintaining this logic would not 
outway the expense of building the object file twice. If that expense is 
prohibitive to the user, then perhaps they should think about putting 
the shared file into a library, or barring that, specifying the object 
as a target file outright.

> Ok... well, I think I should stop thinking as V2 user and as V2 
> developer propose something. That something is:
> 
> 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.

Christopher