automake-patches
[Top][All Lists]
Advanced

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

Re: 1.6.2: patch-multi-inputs


From: Harlan Stenn
Subject: Re: 1.6.2: patch-multi-inputs
Date: Wed, 31 Jul 2002 16:21:08 -0700

> This patch also lacks a ChangeLog entry and a test case.
> You'll have to sign up an FSF assignment before we can
> install a patch of this size.  I'll send you the form.

Thanks, I'll fill it out and send it back in.

It's been over a month since I wrote this patch; I know it works here and
that's about all.

The situation is the original code expected that multiple input files
ASSUMED that the first input file was a Makefile.in.  I had a case where
this is not true.

I noticed that if we are producing a Makefile from a Makefile.in, we
apparently need to find exactly 1 Makefile.am from the list of inputs IFF
automake has to produce the Makefile.in .

I kept the "die"s in there because the original code had them.

For one project I need to get the "definitions" of variables Early in the
makefile so dependencies work.  I'm now writing:

 AC_CONFIG_FILES(global-vars.mk)    # holds the variable definitions
 AC_CONFIG_FILES(Makefile:global-vars.mk:Makefile.in)
 (lots more AC_CONFIG_FILES() for the various Makefiles follow)

More below...

> [...]
> 
> | +     ### Original
> | +     # Note that we only examine the first ":" file to see if it is
> | +     # automake input; the rest are just taken verbatim.  We still keep
> | +     # all the files around for dependency checking, however.
> | +     #$input =~ s/\.in$//
> | +     #  or die "$me: invalid input file name `$arg'\n.";
> | +     ### New
> | +     # Look for *.in for which *.am exists.
> 
> Frankly, describing the new behavior is the only thing that
> matters here.  Keeping track of the old code is the job of CVS.

We're talking about "hair" and I wanted to make sure the am-wizards could
easily see what I was trying to do and compare it with previous behavior.  I
expect that when the dust settles the actual patch will be cleaner.

> | +     my @done = ();
> | +   InAm1:
> | +     {
> | +       do
> | +         {
> | +           if (($input =~ /^(.*)\.in$/) && -f $1.".am")
> | +             {
> | +               $input = $1;
> | +               unshift @rest, @done;
> | +               last InAm1;
> | +             }
> | +           else
> | +             {
> | +               push @done, $input;
> | +               $input = shift @rest;
> | +             }
> | +         }
> | +           while $input;
> | +     }
> 
> The purpose of this loop seems the remove the right "input" from
> @rest, so that it doesn't appears as dependency in
> $output_files.  How important is this?

No idea.  I believe the original code did this but it assumed the
Makefile.in would be the first in the list; I simply maintained the existing
behavior.

> I'd say it seems cleaner to preserve all dependencies in
> $output_files and teach handle_configure to not add `$input' to
> those already listed.  If we do this, the current code can be
> simplified to something around the lines of (completly untested,
> but you get the idea):
> 
>   my $input;
>   my ($local, @rest) = split (/:/, $arg);
>   @rest = ($local,) unless  @rest;
>   # The input file is the first dependency we found for which
>   # the `.am' file exists.
>   foreach my $file (@rest)
>     {
>        if (($file =~ /^(.*)\.in$/) && -f $1.".am")
>          {
>             $file = $input;
>             last;
>          }
>     }
>   err "no input file found in `$arg'\n" unless ($input);
>   push (@input_files, $input);
>   $output_files{$input} = $arg;

I believe you.

H



reply via email to

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