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

From: Jürgen Hunold (hunold_at_[hidden])
Date: 2004-11-25 05:15:13

Hi Volodya !

Sorry for the late response, I was on short holiday ;-)

On Monday 22 November 2004 09:00, Vladimir Prus wrote:
> Hi Juergen,
>
> > 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.

Yes, I figured that out.

> > > > 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 not when I use "use-project" and reference them. 

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

Well, yes. But I thought about that issue for the last days and have 
come to the conclusion that this is my problem alone and should not 
disturb the clean design. I'll just document the "out-of-version" 
controlled files and check them into a separate module which then can 
be checked out "on top" of the rest of my projects.

So, please go ahead.

I think we have much more serious problems to solve ;-))

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

Good.

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

But this is true for "Makefile", too. So nothing gained, nothing 
lost ;-)

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