Boost logo

Boost-Build :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-27 12:06:04


----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

>
> I've some questions concerning building semantics
> (see
>
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build_B
uilding_Semantics)
>
> 1. Shouldn't there be some some underlying level, with rules like
> actions -- attaches actions to a target
> generate -- generates a target from sources using specified command line
> generate_in_dir -- ditto, only sources must reside in the same subdir, cd
to
> which is performed prior to building. This is to support tools that
generate
> something in current dir.

I agree that something like this would be appropriate.

> Is there any need to support globbing? Haven't needed it myself, but there
> may be valid needs for such a feature (although it might require changes
to
> jam)

I hope we don't need it. One alternative would be to take advantage of
two-stage or recursive invocation, by redirecting the result of "ls -1" (or
equivalent) into a file which will be read by Jam.

> Any addition to this list?

I hope not. I'm tired of working on the core!

> 2. There should be a way to toolsets to specify extra files generated,
e.g.
> tds file bcc linker uses to store debugging info, so that those files are
> cleaned.

Absolutely!

> Also, jam docs say that tools which generate fixed name files (yacc?) can
> conflict with mutliple jobs feature? Need to address it?

A decent yacc (bison) has an option to say where the output files go. I'm
not that ambitious yet; I just want to see non-parallel builds work with all
of the features we're talking about.

> (This, of cause, is of low priority, but probably we should be ready to
fix
> this problem some time in future)

OK

 


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