Re: [jamboost] Wrapping up new design

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-01-02 00:08:37

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

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

Because I thought that it would be the easiest way to support the shorthand of
just typing "bjam" and having it act the boost way (without setting the
BOOST_* variables), and while still suppoprting typing "jam" and having it act
the Jam/MR compatible way.

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

Yea, that's how I originally tried doing it, but that was before I ran into
the bootstrap problem of having to define one of the BOOST_* variables before
invoking "jam" to make it use the boost build system files. So it sounds like
a fine way of doing it to me :-)

But a question then... Are you then dropping backward Jam/MR compatability?

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

Ignore it ;-] I think I was thinking of specifying things relative to the
project. So it seems pointless now with your other ideas.

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

Now that is more sensible and obvious what the files are for then!

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

Hmm, yes I think so. I'll take a look at the code and see. Espcially if it
increases the likelyhood of getting the crawl up the directories behaviour
implemented ;-) , which is rather more important to me.

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