Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 6 Mar 2015 18:00:15 -0600

Hi Ben,

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.

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.

Committed to 3.14 branch.

- Andrew
-- 
Doctorow's Law: Anytime someone puts a lock on something you own,
    against your wishes, and doesn't give you the key, they're
    not doing it for your benefit.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System