Boost logo

Boost-Build :

From: Peter Foley (pjfoley_at_[hidden])
Date: 2005-07-08 02:20:46

Hi Volodya,

I should probably give you a better idea of the directory layout. Currently
the layout looks like:

******* Directory layout *********
(Note: "-" is a directory and "*" is a file)

* boost-build.jam
* jamfile.v2
* project-root.jam
- binary
* banner.jpeg
* complete.ico
* custom.ico
* exlam.ico
- gui
* ui.wxs
- includes
* constants.wxi
* gui_constants.wxi
* paths.wxi
- tools
* bjam.wxs

This is not a complete layout of the directory structure just enough to give
you an idea of the layout and purpose of the structure.

When I build this project I execute bjam from the "msi_wix/build/"

As stated the jamfile.v2 looks like:


# WIX Boost installer Jamfile

project boost_inst
: source-location ../src
: build-dir msi

msi boost
: installer.wxs
: <include>includes

>From my understanding of the way bjam works it will search for the source
files in the location specified by "source_location". This is fine and it
all works. It does the right thing and passes the full path to the source
files (the *.wxs files) to candle correctly.

The issue crops up when candle.exe trys to find the include files. As you
can see I am passing the include files using the "-I" parameter.

Since candle is being envoked from the "msi_wix/build" directory when it
processes a *.wxs file that has an include directive it is trying to find
the include file in "msi_wix/build/includes" this is obviously incorrect.

Now after thinking further about it I guessed incorrectly, I was expecting
that all paths would be relative to the "source_location" path, but on
reflection this may not be the case. If the user defines and include path
like this "<include>d:\dev\headers" this will obviously not work. It would
end up being "../src/d:\dev\headers" which is quite clearly not a valid

So I guess for the <include> directive it will have to be explicit and not

This solves the compile action but I still have an issue with the linker

I really do need to be able to pass the "source_location". Look at the link
action again:

$(.LD) -nologo "$(OPTIONS)" -b ../src -out "$(<)" "$(>)"

Notice the "-b ../src", from the light.exe help the -b option means:
"-b base path to locate all files (default: current

This is important because the binary files are only included when light
links them into the final MSI file.

Here is an extract from the ui.wxs file:

<Binary Id="Up" src="Binary\Up.ico" />
<Binary Id="New" src="Binary\New.ico" />
<Binary Id="custicon" src="Binary\Custom.ico" />
<Binary Id="repairic" src="Binary\Repair.ico" />
<Binary Id="exclamic" src="Binary\Exclam.ico" />
<Binary Id="removico" src="Binary\Remove.ico" />
<Binary Id="completi" src="Binary\Complete.ico" />
<Binary Id="insticon" src="Binary\Typical.ico" />
<Binary Id="info" src="Binary\Info.ico" />
<Binary Id="bannrbmp" src="Binary\banner.bmp" />
<Binary Id="dlgbmp" src="Binary\dialog.bmp" />

As you can see from the src attribute the path is just "Binary" and then the

In your experience do you think I should define another feature and call it
base_path or something and then do:

$(.LD) -nologo "$(OPTIONS)" -b "$(base_path)" -out "$(<)" "$(>)"

Or should I try to use the "source_location" variable if there is one.

What do you think?



"Vladimir Prus" <ghost_at_[hidden]> wrote in message
> On Thursday 07 July 2005 14:20, Peter Foley wrote:
> > Hi List,
> >
> > During the development of the wix.jam file to make it easier for me to
> > develop I hard coded various values. I am at the stage where I am
> > to remove the bit where I hardcode "../src" (see the compile and link
> > actions below):
> >
> > ----
> > actions compile
> > {
> > $(.CC) -nologo "$(OPTIONS)" -d"$(DEFINES)" -I../src/"$(INCLUDES)"
> > "$(<)" "$(>)"
> > }
> This is strange. Why do you prepend source dir? I suspect that it won't
> Say, you have
> <include>foo
> If this happens in child Jamfile, when building from top-level dir this
> be translated to something like.
> <include>subproject1/subproject2/build/foo
> Concatenating it with "subproject1/subproject2/build/../src (the source
> location) will give:
> subproject1/subproject2/src/subproject1/subproject2/build/foo
> which is likely to be wrong.
> Either we need to decide that <include> should be treated relative to
> location, and not Jamfile location (no opinion yet), or you'd have to use
> <include>../src/whatever
> Note also that source-location can contain several directories, which
> complicates the matter even more.
> - Volodya
> --
> Vladimir Prus
> Boost.Build V2:
> Yahoo! Groups Links


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at