Boost logo

Boost :

From: Trevor Taylor (xju_at_[hidden])
Date: 2003-05-13 06:34:38


Hi,

I set out to use Boost Jam to build my latest little experiment. I have
some questions/comments:

Why does it build everything into a target-specific subdirectory?
----------------------------------------------------------------

I have lots of classes and tests and tend to build up my Jamfile to
reflect their inter-dependencies, e.g.

     a.cc =
        a.cc
        $(b.cc) ;

     c.cc =
        a.cc
        $(b.cc) ;

     b.cc = b.cc ;

     exe a : $(a.cc) ....
     exe c : $(c.cc)

But building a and c compiles c.cc twice (once into
bin/a.exe/gcc/debug/runtime-link-dynamic/b.o and once into
bin/c.exe/gcc/debug/runtime-link-dynamic/b.o

I would have thought bin/gcc/debug/b.o would have been enough. Why would
  the b.o produced depend on which executable it was bound for? Why
would it depend on wether it was bound for a dll or not?

I modified my boost/tools/build/boost-base.jam to at least remove the
a.exe level so I didn't spend all night watching the compiler.

Where are "compile and link flag" equivalents documented?
--------------------------------------------------------

I wanted to link against libxerces.a that I had built separately, but
couldn't figure out how to specify the equivalent of -L/blah -lxerces.

How does one add a rule for building C++ files from e.g. IDL?
-------------------------------------------------------------

In my case I am using Qt which needs me to run its "moc" compiler to
generate a .cc from my .hh. I put in:

        rule moc
        {
           DEPENDS $(<) : $(>) ;
        }
        actions moc
        {
           "$(QTDIR)/bin/moc.exe" "-o" $(1) $(2)
        }

        moc mTasks.cc : Tasks.hh ;

But somehow that resulted in either Boost Jam looking for something like
  bin/a.exe/gcc.../Tasks.hh or insisting on recompiling mTasks.cc
everytime (bjam -d output suggested Tasks.hh didn't exist, when clearly
it did).

Thanks for any help,

Trevor


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk