Re: [jamboost] Wrapping up new design

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-01-01 22:20:53

On 2002-01-01 at 08:05 PM, david.abrahams_at_[hidden] (David Abrahams) wrote:

>
>----- 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 far it's the easiest to use, understand, and manipulate. And since I had in
the past "given up" on the Jam/MR Perforce version, it's a great job you've
done in making it to the state it is.

>> >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?

Ahh, yes you are missing something, my fault for not elaborating :-) Even
though I'm using boost I'm not "installing" or "building" boost with the
Jamfiles from boost, or from the installer. I instead have my own
"tools/build" directory in my project that I've changed from the boost
distribution. And compile only the files I need from boost directly, along
with the rest of the files from my project. So the reason I see it this way is
that I have a layout like so:

CVSROOT/com/redshift-software/projects/Thot/product/tools/build/*.jam
CVSROOT/com/redshift-software/projects/Thot/product/Jamrules
CVSROOT/com/redshift-software/projects/Thot/product/Jamfile
CVSROOT/com/redshift-software/projects/Thot/product/test/some_test/Jamfile

>> 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?

Yes, like the second. Starting from any subdirectory in the project crawl up
looking for a root level file, Jamrules right now might be a choice, and using
its location to find the build system files. To take my above setup as an
example... I would like to be able to invoke it from
.../product/test/some_test and have it travel up until it finds my local
project root .../product. Right now I do this exact thing with a shell script
placed in each project subdirectory like this:
~~~~~~~~~~~
#! /bin/sh

echo RUNNING BUILD IN "$PWD"...

if test -z "$CONTEXT"; then
CONTEXT=`basename $PWD`
ROOT=".."
else
CONTEXT=`basename $PWD`/$CONTEXT
ROOT=".."/$ROOT
fi

cd ..
source ./build $*
~~~~~~~~~~~
And at the .../product level I have a different "build" script that uses
$CONTEXT variable to invoke jam like this:
~~~~~~~~~~~
#! /bin/sh

echo RUNNING BUILD IN "$PWD"...

STLPORT=no
case "$OSTYPE" in
*linux*)
STLPORT=yes
;;
esac

export GCC_VERSION
GCC_VERSION=`gcc --version`

case "$GCC_VERSION" in
2\.9[5-9] | 3\.*)
TOOL=gcc
;;
esac

if test "$STLPORT" == "yes"; then
TOOL=$TOOL-stlport
fi

JAM_ARGS="-sBOOST_ROOT=$PWD -sTOOLS=\"$TOOL\""

if ! test -z "$CONTEXT"; then
cd $CONTEXT
fi

ONE=$1
shift
REST="$*"

if ! test -z "$ONE"; then
OLDIFS="$IFS"
IFS=","
set $ONE
IFS="$OLDIFS"
fi

if ! test -z "$2"; then
JAM_ARGS="$JAM_ARGS -sBUILD=\"$2\""
fi

if ! test -z "$1"; then
JAM_ARGS="$JAM_ARGS $1"
fi

echo "######################################################################"
echo "$CONTEXT : jam $REST $JAM_ARGS"
echo "######################################################################"

jam $REST $JAM_ARGS
~~~~~~~~~~~

Which lets me, with no additional setup other than having "jam" somewhere in
the exe path, type in:
[while in the .../product/test/some_test directory]
./build my_test
...or...
./build my_test,thot-profile

>> 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.
oops, that should be c & d :-]
>>
>> 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?

I guess given that I don't actually use BOOST_BUILD_PATH c&d don't really
mater much to me :-\ But having a&b would let me get rid of what I consider
kludge "build" scripts that only work on *nix systems.

But the only superior aspect of it is that it doesn't encode build knowledge
in some install howto document, but instead in the build program itself. After
the 20th time of explaining to a developer how to install and setup things I
got tired of it. So if I just say type "./build" anywhere in the project I
save lots of time for me and my developers.

>> 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?

The one situation I can think of where doing it on a per project basis is if
the project uses it's own version of a tool, lex and yacc come to mind. And
therefore you would override those so that not only do they get used, but
possibly also built before getting used. But then again that would mean that
tools would also need to be targets, and I don't know if you want to support
dealing with that pain.

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

Yep, that's the usual model that I work with. For example I have the following
in my CVS tree:

CVSROOT/com/redshift-software/sdk/Boost
CVSROOT/com/redshift-software/sdk/STLport
...and a few more alien/external sdks/libraries.

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

Yes, I see. That is better than what I suggested.

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

Again, that makes more sense :-) Didn't realize you where thinking of having a
project-config.jam file.

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

The only argument for it is laziness :-] Windows is the big pain in the ass
for openning files without extensions. And even the default Gnome and KDE
installs use MIME+extension maps to open files.

Maybe just supporting "Jamfile.jam" as an alternate spelling would be enough
to provide the convenience without complicating the implementation all that
much.

>> 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 ;

Yep, that would be more sensible.

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

Yea, building foo.c and bar.c is what I meant. But it seems like a goofball
suggestion on my part now that I think about it. If you are going to the
trouble of using something like *.c you'll end up segragating the code files
anyway. So it's not worth the implementation agravation.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]