Re: [jamboost] Sources with the same name causing 'Duplicate name of actual target'

From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2003-12-09 05:19:08

Hi again,

> > > Going back to Pedro's example:
> > >
> > > lib a : A1/A.cpp A2/A.cpp : <link>static ;
> > > stage stage : a ;
> > >
> > > I am not really sure where to compile those different A.cpp, so that
they
> > > don't conflict. One solution, from
> > >
> > > http://article.gmane.org/gmane.comp.lib.boost.build/1813
> > >
> > > would be to create auxilliary obj targets:
> > >
> > >
> > > obj a1 : A1/A.cpp ;
> > > obj a2 : A2/A.cpp ;
> >
> > I had tried this one too but it's not very intuitive, at least for the
> > "uninitiated".
>
> Any chance that proper docs will make it less confusing?

That would certainly help.

My problem with declaring obj targets is that I have a set of tools for
automatically generating Jamfiles and Visual Studio projects. Anything that
adds specific requirements to a particular source file is a problem. Then
again, I plan to drop Visual Studio as soon as BBv2 performs well enough for
normal development, so I'd rather see performance enhancements than anything
else :-)

I could change the file names too but we usually name a file after the class
it defines and we have classes with the same name in different
namespaces/directories. I reckon that other people may have "administrative"
difficulties changing filenames when porting legacy systems to BBv2.

> > > and then use them. Whether it can be automated, how it can be
automated
> > and
> > > whether it's worth the effort are the questions.
> >
> > What if the name of the obj file were changed in order to mangle the
whole
> > path, e.g. A1___A.obj?
>
> Yep, might work.
>
> > (I have to say that I was never too fond of the idea
> > of simplifying the target paths...)
>
> Can you clarify what's "simplifying target paths" ;-) I this all we doing
is
> stripping directory from source name and then placing the generated target
> into "bin" directory.

As far as I remember, older versions of BBv2 would place the obj of
A/B1/C.cpp A/B2/C.cpp in something like bin/xxx/A/B1/C.obj and
bin/xxx/A/B2/C.obj. This approach would solve the above problem (or at least
I think so).

Pedro