Re: [jamboost] Wrapping up new design

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-01 20:05:00

----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>

> Hm, OK, I think I'll comment now and maybe raise some questions of my own
:-)
>
> And to setup my point of view here... I should say that I'm not using the
> boost build for building boost itself. I'm using it to build my own
somewhat
> large project.

Fantastic! I'm glad that it's proving to be at least useful enough for you
to have not given up on it yet ;-)

> So my take on things is based on how usefull, easy,
> understandable things are from using this in the more general build system
> case. Hopefully this doesn't intrude too much into boost itself, I hope
:-]

Well, Boost.Build is supposed to serve both purposes. I figure if we can do
the general build system thing, we can handle Boost.

> >OK, now my vision for how the build system works:
> >
> >1. Jambase is read. BOOST_BUILD_PATH is set, so none of the default
> > Jambase code takes effect. Instead, we search for the file called
> > boost-build.jam on BOOST_BUILD_PATH and read that.
> >
> > ** the current Jambase gives an error about FTJam toolset
> > definitions etc., if BOOST_BUILD_PATH is not set and the toolset
> > definition is not set either. Probably that message should be
> > extended to say something about setting BOOST_BUILD_PATH so that
> > people are not confused. The FTJam toolset definitions aren't
> > needed unless you're building Jam itself.
>
> This raises one of my current displeasures with building with the current
> system... having to set variables "outside" of the system. To me the ideal
> would be for the system to figure out automatically where things are and
how
> to minimally operate without any upfront setup, other than
> installing/extracting. And yes even if it's only one variable you have to
set.

AFAIK, the Windows installer and RPMs already figure out where your boost
installation is and set up that one environment variable for you. Am I
missing something?

> I would much rather see something like:
>
> a. Change the name of the jam executable to something boost specific,
maybe
> "bjam" or "boostjam".

Why? It might make sense just because the core is so different from Perforce
Jam at this point, but I'm interested in your reasons.

> b. When invoked with the new name, have it search for some top level build
> file from the current directory, and using that to find the "standard"
> tools/build path.

That's pretty unspecific. What did you have in mind?
The current behavior looks for Jamfile in the current directory. I'd rather
not ask people to put the location of the Boost.Build installation in their
Jamfiles. That would make Jamfiles very unportable across installations.
Maybe you'd like it to look in each directory in the path from the current
directory to the root until it finds the top-level file which indicates how
to find the build system installation?

> c. Search through the BOOST_BUILD_PATH if set.
> c. If that fails search for the build directory on some platform specific
> location, i.e. where the build tool was installed.
>
> This makes it so that it can work right out of the box, without any "user"
> work.

This seems like an arbitrary version of what we currently have, only
slightly more complicated. Is it superior?

> And again another saving outside setup work...
>
> It would be nice to have things like site-config.jam and user-config.jam,
or
> more generally *config.jam work, mostly, without having per user
intervention.
> For me I like to setup all the build files for my developers ahead of time
and
> have them work for my project without them doing anything other than
executing
> a "build" command. This means that I do just about everything using
relative
> paths, or self discovery from the current directory. So more specifically
it
> would be nice to:
>
> 1. Not just have empty *config.jam files but usefull common defenitions of
> them

The idea was to have useful defaults, but I suppose a useful common
definition would be equivalent.

> and have ways of overriding their settings/defenitions on a per
> user/site/project basis.

The way you override them on a per-user/per-site basis is to put a
replacement file somewhere in your BOOST_BUILD_PATH which will be found
before the Boost.Build installation directory. Is it really a good idea to
support overriding on a per-project basis?

> 2. Support relative paths for everything based on common locations.

What does "based on common locations" mean?

> So the
> ability to specify where stlport is located relative to the project root,
and
> having it correctly translated and used as a full path from that.

I don't think it makes sense to specify paths relative to the project root
in user-config and site-config, since they are presumably
project-independent files, and the user or site presumably only needs one
installation of STLPort 4.5, not one per project.

On the other hand, many projects will have the alien library source checked
in as part of the project, so I guess it makes sense to make
project-relative location optional. I guess I would want project-relative
locations restricted to "project-config.jam" in that case.

> To do #1 I would suggest that it should be possible to do a
"gcc.configure..."
> after the "using gcc...". For example:
>
> using gcc : 2.95.3 gcc-2.95.3
> 3.0.2 gcc-3.0.2
> : <prefix>/usr/local
> ;
> # Only resets the "standard" location of gcc tools.
> gcc.configure : <prefix>/usr/local/gcc-tools ;

Yes, I had intended something like this. In fact, if all of your gcc
toolsets were installed under a common prefix directory (e.g.
/usr/local/gcc-tools/2.95.3, /usr/local/gcc-tools/3.0.2, ...), the
enumeration of versions in the "using" invocation shouldn't be needed at
all. I would have written:

using gcc ;
gcc.prefix /usr/local/gcc-tools ;

I don't see any point in trying to shunt all of this configuration through a
single "configure" rule.

> For stlport type tool additives there is one problem which I'm not sure
how
> boost developers tackle right now. For me I end up building stlport with
each
> different gcc version I'm using (2.96 & 3.0.3 right now, more later). I
> created my own build script which deposits different "lib" directories in
the
> stlport directory, which happens to be someplace in my cvs tree. I end up
with
> "stlport/lib-gcc-2.96" and "stlport/lib-gcc-3.0.3" directories.

Yeah; I expect that pretty quickly we'd be able to build the STLport
libraries with Boost.Build, also...

> So supporting that in an orthagonal way to the stlport version itself
would be
> essential for me.

I understand.

> As for relative paths taking the configre after using type use it would be
> nice to be able to do something like:
>
> using stlport...
> # Locate the stlport location relative to the project root. "@" is what
> # you suggested for project naming stuff, so maybe that's not a good
> # choice here.
> stlport.configure 4.5 stlport : <prefix>@/../../sdk ;

Why bother with @/ ?
In project-config.jam, you just write:

using stlport : 4.5 ../../sdk ; # relative paths are w.r.t. the project root

> > project.jamfile-location( root-to-jamfile )
> >
> > Declares the location of this Jamfile with respect to the
> > project root, in case the path given in the project rule does
> > not describe the location of the jamfile.
>
> Changing the name of the Jamfile would also be nice to have, especially
for
> platforms that need file extensions (win32).

Win32 Jamfiles currently don't have an extension. I don't see any arguments
for or against the feature you propose, other than it would be nice to have/
it's one more thing to implement.

> So maybe:
>
> project.jamfile ( [ <name>jamfile-name ] [ <location>jamfile-location ] )
>
> So one can then do:
>
> project.jamfile <name>foobar.jam ;
> ...and...
> project.jamfile <name>foobar.jam <location>build ;
> ...and...
> project.jamfile <location>build ;

Not bad.

> Extreme suggestion here :-) The following would be cool to have:
>
> project.source <location>src <pattern>*.c ;
>
> # builds all the "c" files in the "src" directory.
> exe foobar : * ;

Not so extreme. I think Toon wanted to do something similar, but I think
this makes more sense:

project my-project : <source-location>src ;
exe foobar : *.c ;

> ...and/or...
> exe foobar : foo bar ;

I don't understand this one. Are you suggesting foobar is built of foo.c and
bar.c?
Is the complication really worth it? All you're saving here is the writing
the extension down.