From: David Abrahams (dave_at_[hidden])
Date: 2006-12-11 08:11:25
Rene Rivera <grafikrobot_at_[hidden]> writes:
> David Abrahams wrote:
>> Rene Rivera <grafikrobot_at_[hidden]> writes:
> Since the http://boost.cvs.sourceforge.net/boost/website is a root
> separate from the http://boost.cvs.sourceforge.net/boost/boost root it
> is not affected by changes to
>>> I do have a preferential objection. I prefer the more lucid "build.jam"
>>> name than any of the others.
> [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
> 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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk