uild.jam?

Rene Rivera <grafikrobotgmail.com> writes:

> David Abrahams wrote:
>> Rene Rivera <grafikrobotgmail.com> writes:
>> 
> Since the http:/
/boost.cvs.sourceforge.net/boost/website is a root 
> separate from the http://b
oost.cvs.sourceforge.net/boost/boost root it 
> is not affected by changes to 
> http://boost.cvs.sourceforge.net/boost/boost/Jamroot.

OK, thanks.

>>> I do have a preferential objection. I prefer
the more lucid "build.jam" 
>>> name than any of the others. 
>> 
>> Lucid?
>
> [Merriam-Webster] 3 : clear to the understanding :
INTELLIGIBLE

I know what it means; I just question the lucidity of
"build.jam"

>>> And as I've mentioned before having an
extension on the file names
>>> is considerably more convenient on people as it
lets them
>>> integrate with the OS facilities.
>> 
>> I understand that argument, but it's hard to see
build.jam as a
>> particularly lucid name.  That's like naming a C++
source file
>> run.cpp.
>
> I've seen "run.cpp" many times, 

That doesn't make it descriptive.

> specifically as a common name when the file defines
"main()". I've
> also seen main.cpp for same purpose.

That is at least somewhat descriptive.

>> At least Jamfile and Jamroot visibly distinguish
themselves as user
>> build descriptions as opposed to parts of the build
system itself.
>
> Opinions vary 

You don't think they distinguish themselves from build
system files?
How would you make them more distinct?

I'm not arguing with you about the suffix, FWIW.

>> Also, I note that we don't have a .jam-suffixed
name for Jamroot.
>
> We do in project.jam:
>
> JAMROOT ?= project-root.jam [Jj]amroot [Jj]amroot.jam ;

Oh, great 

>>>> Secondly, is there any reason we can't
change the pattern to 

>> Sounds good to me... although I see project.jam
looking in the global
>> module (presumably to get JAMFILE out of the
environment) first, which
>> seems like a mistake.
>
> I believe it's so that one can set it in the
boost-build.jam file as 
> that file loads into the global module. Hence why the
line you want to 
> change in that file works 

Uuuuughhh.  This legacy of picking up environment variables
is going
to dog us forever, isn't it?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

David Abrahams wrote:
> Rene Rivera <grafikrobotgmail.com> writes:
>> David Abrahams wrote:
>>> Rene Rivera <grafikrobotgmail.com> writes:
>>>
>> I've seen "run.cpp" many times, 
> 
> That doesn't make it descriptive.

Well it's at least descriptive to the people who use it 


>>> At least Jamfile and Jamroot visibly
distinguish themselves as user
>>> build descriptions as opposed to parts of the
build system itself.
>> Opinions vary 
> 
> You don't think they distinguish themselves from build
system files?

If by build system files you mean the stuff inside 
boost-root/tools/build/v2 then, they are distinct from build
system 
files. But as Phillip points out, they are not distinct from

Perforce/Jam files. Which is particularly important since
that's what 
users see.

> How would you make them more distinct?

Not use names that Perforce/Jam uses 

> I'm not arguing with you about the suffix, FWIW.

OK. By the way if you search the archives, once upon a time
you also 
agreed about the "build.jam" name 


> Uuuuughhh.  This legacy of picking up environment
variables is going
> to dog us forever, isn't it?

We can choose to abandon that legacy at some point. After
all we can 
just remove the import of the env into the global module in
bjam.


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software
.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build