Re: [boost] build free-features

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-21 09:52:39

----- Original Message -----
From: "Thomas Witt" <witt_at_[hidden]>

> My problem is that direct deps can't handle our project structure very
well.
>
> It looks like this
>
> root/
>    lib1/
>       cpp/
>    lib2/
>       cpp/
>    app1/
>        cpp/
>    app2/
>        cpp/
>
> LibX are static libs that will be linked to both apps, so directory
structure
> cannot reflect dependencies. To improve convenience I placed redirecting
> Jamfiles in the cpp dirs that look like this
>
> -------
> subproject lib1/cpp ;
>
> subinclude . ;
> ----
>
> As a result jam can be invoked from every project directory. With my
current
> emacs compile configuration this is a must.

The subinclude isn't neccessary to be able to invoke Jam from a subproject
directory. Normally, invoking jam in a subproject builds that subproject and
the things it depends on. In a large project you typically don't want to
invoke a full-project build from every subproject -- you need to be able to
work on an isolated piece.

Maybe when YOU invoke jam it builds the entire project regardless of which
subdirectory you're in?

> Is there a better way to handle this ?

Not sure what you're trying to accomplish yet...

> >
> > I don't see how propagation to a dependent target could be relevant; the
> > build proceeds from the target you specify to all of its dependencies,
not
> > the other way around.
>
> I do not understand this.

dll x : x.cpp y.cpp ;

You request that x be built. It is a fake target, whose dependency is x.dll.
x.dll depends on x.obj and y.obj. x.obj depends on x.cpp, etc.

The point is that targets which are DEPENDENT on these aren't built: they're
not part of the build request.

(It took me a long time to understand this, but people use dependent and
dependency to mean opposites. If A depends on B, A is the dependent and B is
the dependency.)

> > I know that free features are not propagated to top-level targets which
are
> > specified as dependencies with <lib>name. That's because free features
are
> > assumed to not affect link-compatibility, so you may already have a
> > suitable build of the dependency lying around.
>
> I don't think the argument is valid. I would argue exact the other way
round.
> As they do not affect link-c. they can be propagated. If they are
propagated
> the suitable build will still be found. The set of rebuilt files will be
the
> same in both cases(Did I miss something?).

Not exactly. Although they aren't supposed to affect link-compatibility,
they usually /will/ affect the built products. I just didn't think it was a
good idea to do anything that would leave around an odd version of a
dependency target which was built indirectly, rather than explicitly.

> I think of free-features as a way to specify how the build should behave.
> Think of a msgstyle feature for metrowerks or something like <cflags>-v.
In
> my oppinion build behaviour should be the same for all targets(as long as
> they don't require different) of one jam invocation.

Hmm; I understand. Maybe it makes sense to distinguish features that don't
affect the built products at all from features which don't affect link
compatibility but do affect the built product. For example, msgstyle,
warnings, template instantiation depth, etc. are in the first category. Most
<define> settings are in the 2nd category.

> > You can affect the BUILD settings of all targets which don't have an
> > explicit default build specification by setting the default-BUILD
variable.
> > Perhaps this mechanism isn't too well thought out, and something more
> > explicit is needed...
>
> To me this feels overly clever. Commandline variables should behave like
> environment variables. Otherwise new user will have a hard time finding
> out.

I agree that it's not easily understood. I'm not sure that it would be right
to propagate ALL free features.

> As a sidenote I use the commandline variables to handle build behaviour
and
> toolset in emacs (I need to change this on-the-fly).

Me, too. If you want the regexps to parse the CW msgstyle that the toolset
provides by default, I have added them at the end. I used to use msgstyle
gcc but these messages are much more informative so I fixed my .emacs error
parsing ;-)

-Dave

----------

;; Make sure we have a definition of compilation-error-regexp-alist before
;; modifying it
(require 'compile)

(setq compilation-error-regexp-alist
      (append
       '(
         ;; This expression can be used to match error messages from Jam
         ("\"?\\([a-zA-Z]?:?[^\":\n]+\\)\"?:[   ]+[Ll]ine[  ]+\\([0-9]+\\)"
1 2)

         ;; This expression matches metrowerks command-line tool output. We
just
         ;; pick up the line number, since the file name is handled below
         ("\\(### mw[^\n]+\n\\)?# +\\([0-9]+\\):" nil 2)
         )
       compilation-error-regexp-alist))

(setq compilation-file-regexp-alist
      (append
       '(
         ;; This expression matches metrowerks command-line tool output,
which
         ;; only displays the filename once for multiple errors
         ("### mw[^\n]+\n# *In: \"?\\([a-zA-Z]?:?[^\":\n]+\\)\"?$" 1)
         ("### mw[^\n]+\n# *File: \"?\\([a-zA-Z]?:?[^\":\n]+\\)\"?$" 1)
         ("^(\\(.*\.tex\\)\\{.*tex.cfg\\}\nLaTeX2e" 1)
         )
       compilation-file-regexp-alist))