Re: [jamboost] Bjam newbie

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-09-17 01:48:46

Paul Hamilton wrote:

> 1) How do I specify n external dependancy in my .jam files?
>
> Imagine this:
>
> run unit_test.cpp
>
> : #args
> :
> : test.xml pattern.test
> :
> : <sysinclude>$(PROJECT_ROOT) <sysinclude>$(BOOST_ROOT)
>
> ;
>
> Now it just so happens that "test.xml" is not self contained, because
> it "includes" another file called "test2.xml" (it includes it using an
> internal mechanism of the test program).
>
> I can't just put "test2.xml" in the args, because I don't want it
> actually passed to the program. When I change test2.xml, I want it to
> re-run the test.

I don't think it's possible cleanly. I recall I did something like that a long 
time ago, but forgot how exactly and my case was simpler. The trick was to 
get internal target names and use builtin DEPENDS. Maybe, someone else know 
better way.

> 2) How do I override compiler settings which are defaults on a build.
> For example I always want to build both debug and release without
> inlining in darwin (for example).
>
> I guess I would place <inlining>off somewhere in the following of my
> jam file right?
>
> dll schemalib_ : $(SCHEMA_PATH)/$(CPP_SOURCES).cpp
>
> : <sysinclude>$(PROJECT_ROOT) <sysinclude>$(BOOST_ROOT)
> :
> : debug release
>
> ;

Maybe, putting <darwin><*><inlining>off in requirements will help.

> 3) What is the actual philosophical driving force behind the whole "v2"
> thing? Should I be using v2 on all new projects? What will be the main
> important features of "v2" over "v1" jam files?

There's no philosophical driving force --- only practical ones. I don't have a 
complete list ready, but some of advantages are:

- configuration is simpler: you edit a single file as opposed to tweaking 
environmental vars
- V2 has no problems with several versions of the same compiler
- there are "usage-requirements" -- you just mention a library in sources and 
get all necessary includes/defines automatically
- the Jamfile syntax is a bit simpler, you don't need <lib> prefixes, and 
projects can declare requirements which apply to all targets in that project
- things like stlport support are much better. In v1 there's 'gcc.jam' and 
'gcc-stlport.jam' toolsets, and the same for msvc. In v2, stlport support is 
orthogonal and should work will all toolsets automatically.
- adding our own custom tools (not only compilers) is much easier that in v1

As for using v2 on new projects: I'd say this is not unreasonable. The primary 
problem for now is performance --- which is being addressed. As for 
bugs/features --- v1 might be more mature, but, for example, the feature 
request from point 1) above might be implemented in a clean way in V2 in a 
couple of hours. 

If you decide to use v2, though, you probably should wait till regression 
testing system, which you seem to use, it implemented --- which is likely to 
be done in the next milestone release.

- Volodya