bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing *-local hooking


From: Akim Demaille
Subject: Re: Missing *-local hooking
Date: Sun, 25 Nov 2007 18:01:46 +0100


Le 20 nov. 07 à 22:04, Ralf Wildenhues a écrit :

Hi Akim,

* Akim Demaille wrote on Mon, Nov 19, 2007 at 03:25:51PM CET:
Automake does not notice the use of *-local targets
when defined together:

Go ahead if you'd like to commit this as a currently-XFAILing test,
but even better if you fix it.  :-)

See this comment in automake.in:file_contents_internal:

Actually it is not connected: file_contents_internal is never
used to read user Makefile.ams.  It was my goal at the
time I was hacking that code, that's why there is an argument
"$is_am" which is defined and used, but the function is always
called with $is_am == 1.  I don't know if someone will want
to finish the needed changes to fuse the lib/am/*.am and
Makefile.am parsers.  Also, I have always been tempted to
use some fully blown template engine to move even more code
in the *.am files.  For instance <http://template-toolkit.org>.



The problem here is quite deep: Automake seems to be
using interchangeably "rulename" and "target", the
former being a list of the latter.  Here for instance,
we check that:

  # Install the -local hooks.
  foreach (keys %dependencies)
    {
      # Hooks are installed on the -am targets.
      s/-am$// or next;
      depend ("$_-am", "$_-local")
        if user_phony_rule "$_-local";
    }

and user_phony_rule is using &rule:

sub rule ($)
{
  my ($name) = @_;
  # Strip $(EXEEXT) from $name, so we can diagnose
  # a clash if `ctags$(EXEEXT):' is redefined after `ctags:'.
  $name =~ s,\$\(EXEEXT\)$,,;
  return $_rule_dict{$name} || 0;
}

but _rule_dict is filled by calls to Rule::define like
this one (for user Makefile.am):

        elsif (/$RULE_PATTERN/o)
        {
            # Found a rule.
            $prev_state = IN_RULE_DEF;

            # For now we have to output all definitions of user rules
            # and can't diagnose duplicates (see the comment in
            # Automake::Rule::define). So we go on and ignore the return value.
            Automake::Rule::define ($1, $amfile, RULE_USER, $cond, $where);

In other words, we mix two styles of uses of _rule_dict,
and the right fix for all.test is to make a deep clean.
For instance even &rule above is wrong if we define
several targets with $(EXEEXT) in a single rule.  I have
seem many similar places in the code.

I'm afraid that simply splitting the keys would duplicate
the rule in the Makefile instead of sharing.

My favorite approach would be do it though, and have
another pass fuse the commands with the same targets
and dependencies.  But it might result in something
not wanted by the user that I did not consider.

Thoughts?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]