Re: [jamboost] Re: Clean up project-root.jam?

From: Juergen Hunold (hunold_at_[hidden])
Date: 2004-11-21 07:32:04

Hi !

On Friday 19 November 2004 16:00, Vladimir Prus wrote:
> Toon Knapen wrote:
> >> It would be desirable to have only one kind of file, with single
> >> set of allowed rules.
> >
> > I definitly agree !
>
> Ok. FWIW, I decided that since nobody posted "over my dead body"
> replies this suggestions is not that bad, so it's already committed
> (reducing the code size by 8K, btw ;-) ).

Thats good. More than one syntax is confusing.

> >> It's quite possible to use project-root.jam just as different name
> >> of Jamfile. When trying to load project, we look both for Jamfile
> >> and for project-root.jam. If we found Jamfile, we first
> >> lookup/load parent project and then load Jamfile. If we found
> >> project-root.jam, we just load it, without looking up the parent.
> >> The loading process for Jamfile and project-root.jam will be
> >> exactly the same, and the set of rule which can be used in Jamfile
> >> and project-root.jam will be the same.
> >>
> >> For backward compatibility, if a directory contains both
> >> project-root.jam and Jamfile, we'll load both.

Well, it seems that project-root.jam is loaded _everytime_ it is seen,
even when bjam has already loaded a project-root.jam. This happens with 
my cross-project dependencies where I have a project-rpot.jam for 
_each_ project.

> > May I propose soth different: I suggest to have a file 'Jamroot'
> > (or Jamrootfile or soth.) in the root-directory and 'Jamfile'
> > everywher else. Starting all bjam related files with the prefix
> > 'Jam' might confuse people less. And for backward compat. we could
> > say: or you have Jamrootfile or a project-root.jam and Jamfile.

I am not certain that merging the files is a good idea. 
On one hand, I'd prefer two different files with different purposes. 
First, Jamfile with contains project-specific information which must be 
available to other projects, too. 
Second, something like project-root.jam which contain project-specific 
data. This file should not be read when another project refers to the 
corresponding Jamfile. 
I have some cases where this could be the solution to my problems.

But on the other hand this could introduce new problems when two 
projects declare the same feature with different values.
So I'm +0.25 for merging ;-) since I can declare "global" settings in 
user-config.jam or site-config.jam. But there they are not in under per 
project source control.

> The arguments about "Jam" prefix is definitely a valid one. It would
> have to relearn this convention, but new users might benefit. Anybody
> else care to comment on this UI issue? Should we use Jamroot or
> project-root.jam?

Well, I think that Jamfile was choosen as analogy to Makefile. So I 
think it would be good to use Jamroot.
+1 on this from me.
All other "included" files can then retain their ".jam" postfix.

As for IDE-integration, I think that most IDE's can cope with 
"Makefile", so this should not be hard.
And I don't think up with some convention like qmake, TrollTech's 
Makefile-generator. qmake default is to expect "foo.pro" when being in 
directory "foo". You then end up with names like "src.pro" 20 times in 
your project ;-)

Yours, 

Jürgen

-- 
* Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau
* voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover 
* fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover
* hunold_at_[hidden] ! www.ive.uni-hannover.de