autoconf-archive-maintainers
[Top][All Lists]
Advanced

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

Re: Serial lines for Automake


From: Francesco Salvestrini
Subject: Re: Serial lines for Automake
Date: Sat, 18 Jul 2009 19:36:04 +0200
User-agent: KMail/1.9.10

Hi Peter, 

On Saturday 18 July 2009, Peter Simons wrote:
> Hi Francesco,
>
>  > [commit hook validation]
>
> thank you for the explanation. This sounds to me like the #serial lines
> would be added to the m4 files in the Git repository, but we'd use Git
> to guarantee that the serial numbers are bumped every time a macro is
> committed to. Is that right?

Yes, but I'm going to takeback that approach. It couldn't work easily in our 
current model.

We must ensure that the distribution serial numbers are the same, regardless 
of the repository used for building the distribution.

>  >> Say the Archive distributes a macro AX_FOO at version X. Now Joe Doe
>  >> downloads the file, patches AX_FOO, and re-distributes it on his
>  >> homepage. How can Joe compute a serial "X + 1" that won't conflict
>  >> with a version that the Archive might distribute some day?
>  >
>  > # NUMBER1.NUMBER2 COMMENT
>  >
>  > Where NUMBER1 is:
>  >
>  >  *) 0 for the archive macros
>  >  *) >= 0 for third-party tweaks/changes/redistribution
>  >
>  > eg:
>  >
>  > # 0.XXXX  Please change 0.XXXX to 1.YYYY if you are going to change this
>  > macro
>
> How does Automake interpret those numbers? Would 0.2 be considered
> "newer" than 1.1? The Automake documentation is a little unclear in that
> regard.

aclocal.in from automake sources uses its own list_compare() for the job:

sub list_compare (address@hidden@)
{
  my @l = @{$_[0]};
  my @r = @{$_[1]};
  while (1)
    {
      if (0 == @l)
        {
          return (0 == @r) ? 0 : -1;
        }
      elsif (0 == @r)
        {
          return 1;
        }
      elsif ($l[0] < $r[0])
        {
          return -1;
        }
      elsif ($l[0] > $r[0])
        {
          return 1;
        }
      shift @l;
      shift @r;
    }
}

This snippet:

my @a = split (/\./, "0");
my @b = split (/\./, "0");
print list_compare(@a, @b) . "\n";

my @a = split (/\./, "0");
my @b = split (/\./, "1");
print list_compare(@a, @b) . "\n";

my @a = split (/\./, "1");
my @b = split (/\./, "0");
print list_compare(@a, @b) . "\n";

my @a = split (/\./, "0.2");
my @b = split (/\./, "1.1");
print list_compare(@a, @b) . "\n";

Outputs:

0
-1
1
-1

That means 0.2 < 1.1 for aclocal.

>  > I don't see a full-fledged-fool-proof solution at the moment. The
>  > solution could solve problems generated by some "misuse" of the archive
>  > itself (eg: the archive installed system-wise and some user copies
>  > scattered in the aclocal include path).
>
> Yes, that's true. Serial lines probably won't provide reliable version
> information for derived macros outside of the archive, but they would
> provide good version information for the macros distributed by the
> archive. It's a not perfect solution, but it's still useful.

We could even use a more conservative approach: 

1) Use an AA_ prefix for all macros
2) Use a non-dotted version serial number

1 -> Since the AX_ is the suggested prefix for thirdy part macros, using a 
different one should avoid some clashes. The AA_ could even be more 
conformant (AC, AM, AH, LT ...)

2 -> To avoid problems using the uncommon format. The single number is the 
format used in automake and gnulib macros after all ...

Ciao,
Francesco

-- 
"Good health" is merely the slowest rate at which one can die.




reply via email to

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