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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-12-09 05:28:01

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

Yes, understood.

> 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 :-)

:-) 
BTW, just now I'm working on a mechanism for replacing any given class method 
or module rule with C code. Hopefully, this will allow to start optimizing 
much faster. 

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

Ok.

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

Hmm.... I'm not sure this was ever so. Anyway, I'll add both A1__A.obj and 
this idea to the issue.

- Volodya