Re: [jamboost] Wrapping up new design

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-01 23:34:01

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

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

<blush> I'm very pleased.

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

OK, I understand what you're doing now.

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

Still waiting for an answer to the above

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

This part's easy enough to do in native Jam.

> and using
> its location to find the build system files.

I don't understand this part. Do you want the build system to be located in
some fixed place relative to the Jamrules file? That sounds like a bad idea
to me. Most people will probably only want one installation of the build
system for their many projects. Why don't we just have it crawl up to find
Jamrules (or whatever), then include that file? You can invoke a rule in
that file which specifies the location of the build system (.jam files).

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

How does the above suggestion sound?

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

That makes sense. If your CVS tree contains the build system files, you
ought to be able to use Jam without any intervention.

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

Eventually, yes, I do. I don't think it's too difficult a special case,
either.

> >> 2. Support relative paths for everything based on common locations.
> >
> >What does "based on common locations" mean?

Still waiting for an answer to the above.

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

OK.

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

It's just a better name for Jamrules ;-)

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

Maybe we should just dispense with "Jamfile" and go with "project.jam"
(taking the place of Jamfile) and "project-config.jam" (taking the place of
Jamrules).

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

The globbing would require another extension to the core Jam source. Would
you like to volunteer?

-Dave