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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-22 03:00:03

Hi Juergen,

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

This is expected. When we load Jamfile, we also load all parent Jamfiles and 
project-root.jam for that Jamfile, even if we loaded project-root.jam for 
other Jamfile. 

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

Could you elaborate? In the current model, definitions in Jamroot/Jamfile will 
apply to all children project. But they won't apply to separate Jamfiles. 

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

So, the issue is that you want some definitions which are available to all 
modules, but due to version control model you use, those definitions can't be 
placed in one place, and must be duplicated everywhere?

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

This gives 4 +1 votes for Jamroot. I'll make the change.

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

;-) OTOH, with Boost.Build you have 20 file named "Jamfile" in the project.

- Volodya