From: brock_peabody (bpyama_at_[hidden])
Date: 2003-10-17 13:23:02
--- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
> brock_peabody wrote:
> > How does one access an environment variable in a jam file? For
> > instance, I want to stage all of my exe's in one directory on my
> > windows box, but in another on my linux box:
> > stage exe : project : <location>$(EXE_DESTINATION) ;
> You can get env var with
> import modules ;
> local EXE_DESTINATION = [ modules.peek : EXE_DESTINATION ] ;
> > Actually, it would be better if there were a different way of
> > it besides environment variables. Any ideas?
> Well... you can put the following in your project-root.jam:
> path-constant EXE_DESTINATION : /path/to/your/dir ;
> You can then change this string dependencing on platform. For
> maintainability you can:
> 1. Create file called "config.jam", or something. Put the above
> "path-constant" line there.
> 2. Add "include config.jam" to your project-root.jam
> 3. Write some tool for generating config.jam, or create different
> different boxes, or something else.
> This last approach is better because modifying a single file which
> directories is simpler than the entire project-root.jam, which can
> > Also, I really like Boost.Build, but it is very hard to get
> > Is there some documentation besides the manual that I don't know
> > about?
> There's a lot of comments in the code. You can look at the source,
or use the
> nice "bjam --help" option.
> > When I look through the boost jam files for examples most of
> > what I see is undocumented. I know this is a work in progress.
> > Would it help for a neophyte like me to catalog undocumented
> > keywords?
> Frankly, I was never told how to write a good documentation. I'm
> issues that user raise into my notes with the hope to act on this
> one day. I think the best approach would be for you to continue
> messages about *any* omissions or obscurities in the
> In fact, I'd appreciate help about documentation structure, as
well. From my
> point of view, the tutorial is okay -- it's better to add an
example for each
> tutorial section, but it's okay anyway.
> But what should be written next? Complete reference of every
> afraid that it will be overwhelming. That's why the current doc
> "reference" section, indended to give only quick reference,
> reference", which document every detail. Is this structure OK? Can
> suggest all stuff which should go into "reference" section? I'd be
> for suggestions.
> - Volodya
> - Volodya
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