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.
> 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
> 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
> > > 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
> > > 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
> > 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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk