Re: Base 3.14.12.5-pre1 Available

[Benjamin Franksen <benjamin.franksen@helmholtz-berlin.de>]

Am Freitag, 6. März 2015, 18:00:15 schrieb Andrew Johnson:
> On 03/04/2015 01:36 PM, Benjamin Franksen wrote:
> >>> 4)
> >>> fix_-release_cfg_config-and-_rules-should-be-in-reverse-order.patch
> >>>
> >>> RULES and CONFIG files from the cfg subdir of other modules must be
> >>> included in the opposite order in which they appear in the
> >>> configure/RELEASE file. This is because the RELEASE file lists them
> >>> in reverse dependency order. This is the correct order when
> >>> creating search paths (because in that case earlier entries win
> >>> over later ones), but not when including make file snippets
> >>> (because in that case later entries win over earlier ones).
> >>
> >> You reversed the include order for the <top>/cfg/CONFIG* and
> >> <top>/cfg/RULES* files, but not for the <top>/configure/RULES_BUILD
> >> files. Wouldn't that make sense too?
> >
> > I think I simply forgot this. Probably because the sequencer is the only
> > module we use that has its own RULES_BUILD and the definitions in there
> > do not overlap with those in base. But in general we can't rely on that,
> > so: yes, definitely.
>
> I discussed the order reversal with Janet. We think it makes sense to
> reverse the order of including the cfg/CONFIG* files since we want
> modules that appear higher in the Release file to take precedence over
> lower modules (the higher modules need to be read later so they're able
> to override variable values set by the lower modules). However for the
> RULES files we think the include order should be the same as listed in
> the Release file.
>
> The manual for Make says that the order in which rules appear in a
> Makefile is not important, other than the first rule which sets the
> default goal. However it does later give two exceptions to that statement:
>  * Double-colon rules are executed in the order they are seen by Make,
> although such rules only really make sense where the order that the
> rules are executed in doesn't matter. Base-3.14 uses double-colon rules
> for clean, but we switched it back to single-colon rules in Base-3.15.
>  * Pattern rules are considered in the order in which Make sees them.
> This is probably the only reason why the order of the cfg/RULES* files
> could matter, and since the first matching rule will win the file order
> for rules should match the order of entries in the Release file.

Thanks for digging this up. I was trying to find it in the gnu make manual
when you brought up the question but failed (should have looked harder). I
guess this might explain some of the trouble I had lately when rules I added
in a Makefile didn't fire unless I turned them into static pattern rules
(which always take precedence over normal pattern rules).

I will try and experiment with going back to including cfg/RULES* in the
original order and see what happens...

> I changed the order back for the cfg/*RULES* includes.
>
> >>> 5) extend-the-cfg-mechanism-to-rules_top.patch
> >>>
> >>> Finally one patch which adds a feature and is not a bug fix: in
> >>> addition to adding RULES in a support module, this allows users to
> >>> add TOP_RULES. In case it is not evident why this is useful, please
> >>> shout and I'll explain.
>
> I extended this idea and added support for cfg/DIR_RULES* files as well.
> These will be included by any Makefile that is not compiling code inside
> an O.arch directory (the cfg/RULES* files are only included by Makefiles
> that are compiling code).
>
> It will be possible to add new make actions that get recursed down the
> tree by adding the action name to the ACTIONS variable in a DIR_RULES
> file. There must also be a rule for that action in cfg/RULES*
>
> For example, put 'ACTIONS += hello' in DIR_RULES and this in RULES:
> hello:
>       @echo "Hello from $(shell pwd)"
> Now 'make hello' prints hello from each of the O.arch directories in the
> application tree.

Interesting. I am not sure I completely understand your remark that
"cfg/RULES* files are only included by Makefiles that are compiling code".
Does that imply cfg/RULES* are only included (via $(TOP)/configure/RULES) if
T_A is defined?

> Committed to 3.14 branch.

Cool, thanks.

Cheers
Ben
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies and the other
way is to make it so complicated that there are no obvious deficiencies.
The first method is far more difficult."   ― C.A.R. Hoare


________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de