Re: [BBv2] [source-location] - Using this variable in compile and link actions

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)

-msi_wix
-build
* boost-build.jam
* jamfile.v2
* project-root.jam
-src
- 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/"
directory.

As stated the jamfile.v2 looks like:

****************************

# WIX Boost installer Jamfile

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

msi boost 
: installer.wxs
./gui/ui.wxs
./tools/bjam.wxs
: <include>includes
<define>Flavor=Test
;
****************************

>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
path.

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

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

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
directory)"

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
filename.

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?

Thanks,

Peter.

"Vladimir Prus" <ghost_at_[hidden]> wrote in message
news:<200507071433.26570.ghost_at_[hidden]>...
> 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
trying
> > 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)"
-out
> > "$(<)" "$(>)"
> > }
> 
> This is strange. Why do you prepend source dir? I suspect that it won't
work. 
> Say, you have
> 
> <include>foo
> 
> If this happens in child Jamfile, when building from top-level dir this
will 
> 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
source 
> 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
> http://vladimir_prus.blogspot.com
> Boost.Build V2: http://boost.org/boost-build2
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> 
>