Re: My patches

[Russ Allbery]

Akim Demaille <[EMAIL PROTECTED]> writes:

> I have a question: what is the version of Perl we can require.  There
> are feature implemented in 5.6 that I would like to use, but is it
> acceptable?

I know Tom already answered this, but just to add a bit more information,
5.6.0 wasn't particularly stable.  It had a few bugs that weren't *huge*,
but which were more than I was comfortable with.  A lot of us are waiting
for 5.6.1.

> More specifically I'm using Class::Struct which was significantly
> improved since 5.005, but its only requirement is:

> use 5.005_64;

> so we can use it with Perl 5.5, provided that we distribute it

Er, 5.005_64 is one of the 5.6.0 pre-releases.  That's not Perl 5.005;
that's equivalent to requiring 5.6.0 for most people.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: My patches

[Akim Demaille]

> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:

Akim> I would like to emphasize that there is a chunk of patches which
Akim> should be applied altogether if we don't want to leave a broken
Akim> Automake in the repo.

Tom> Well, automake should never be broken in the repo.  

OK, then I can apply a batch of patches as a single commit.


Tom> I run Red Hat 6.2, which is a reasonable OS to use.  It isn't
Tom> obsolete yet.  It comes with perl 5.005_03.  I don't know what
Tom> the stable Debian release uses, but we should support that Perl
Tom> as well.

Fine with me, that's why there was another question :)  Any problem
with shipping Class::Struct?

Re: My patches

[Tom Tromey]

> "David" == David Lee <[EMAIL PROTECTED]> writes:

David> One might be tempted to argue that anyone dabbling with
David> automake will already be a keen perl "bleeding edge" junkie;
David> but I would urge caution before leaping to that conclusion.

My real goal is to have 1.5 be reliable enough and complete enough
that (1) people will switch to it en masse, and (2) I can give up
automake hacking.  So I agree.

Tom

Re: My patches

[Tom Tromey]

>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:

Akim> Right now I don't have enough time to apply my patches, I will
Akim> probably do tomorrow Friday, or Saturday, or Sunday, but I will
Akim> try to catch up as soon as possible.

Don't speed up on my account.  I'm gone all next week.

Akim> I would like to emphasize that there is a chunk of patches which
Akim> should be applied altogether if we don't want to leave a broken
Akim> Automake in the repo.

Well, automake should never be broken in the repo.  Anyway I don't
have time to look at patches until at least a week from tomorrow.

Akim> I have a question: what is the version of Perl we can require.
Akim> There are feature implemented in 5.6 that I would like to use,
Akim> but is it acceptable?

I don't think so.  I run Red Hat 6.2, which is a reasonable OS to use.
It isn't obsolete yet.  It comes with perl 5.005_03.  I don't know
what the stable Debian release uses, but we should support that Perl
as well.

Tom

Re: My patches

[David Lee]

On 22 Mar 2001, Akim Demaille wrote:

> [...]
> I have a question: what is the version of Perl we can require.  There
> are feature implemented in 5.6 that I would like to use, but is it
> acceptable?  More specifically I'm using Class::Struct which was
> significantly improved since 5.005, but its only requirement is:
> 
> use 5.005_64;
> 
> so we can use it with Perl 5.5, provided that we distribute it
> (Hm... is it valid wrt licenses?).  Requiring 5.6 is simpler though.
> But if unacceptable, what would you say of using 5.6's Class::Struct?

My vote is for caution: that is, not to impose any limitations (e.g. 
latest version of XYZ) on users of automake that aren't strictly
necessary.

I guess that there are many sites which have gone through the effort of
installing a version of perl5 in the last couple of years, and would _not_
be keen on having to go through the extra effort of an(other) upgrade.

For information: at Solaris 8, Sun started including perl in the system. 

This is a great step forward, because not everyone is keen on having to
install their own perl.  It comes ready made and so is attractive.  (The
"keen" sites can opt to override it (and ours does so), but not everyone
is that "keen".) 

Anyway the Solaris version is: 

   # perl --version
   
   This is perl, version 5.005_03 built for sun4-solaris
   
   Copyright 1987-1999, Larry Wall
   
   Perl may be copied only under the terms of either the Artistic License or the
   GNU General Public License, which may be found in the Perl 5.0 source kit.
   
   Complete documentation for Perl, including FAQ lists, should be found on
   this system using `man perl' or `perldoc perl'.  If you have access to the
   Internet, point your browser at http://www.perl.com/, the Perl Home Page.
   
   # 

One might be tempted to argue that anyone dabbling with automake will
already be a keen perl "bleeding edge" junkie; but I would urge caution
before leaping to that conclusion. 

Hope that helps your thinking through this.


-- 

:  David LeeI.T. Service  :
:  Systems Programmer   Computer Centre   :
:   University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/South Road:
:   Durham:
:  Phone: +44 191 374 2882  U.K.  :

My patches

[Akim Demaille]

Hi Tom,

Good to see you again :)

Right now I don't have enough time to apply my patches, I will
probably do tomorrow Friday, or Saturday, or Sunday, but I will try to
catch up as soon as possible.

I would like to emphasize that there is a chunk of patches which
should be applied altogether if we don't want to leave a broken
Automake in the repo.  As said in the messages corresponding to these
patches (most importantly those related to the revamping of the
handling of variables/macros), the result is quite neat, but the way
to this result was delicate, and I needed several steps to keep
the patches reasonably small.  But some of the steps leave a broken
Automake.

The Automake I have at home fails three tests.  IIRC:

- subcond2
  because it is sensitive to the *indentation* in Makefile, hence it
  is not a semantic failure, purely syntactic.  I'll fix this once
  I know what you preference is (is it Makefile.in or Makefile which
  should fit within 80 cols).

- objc
  because I tend to think there is no reason not to use the OBJC
  linker in the test.  But the converse attitude would be valid too,
  as was explained.  It's a matter of choice.

- 
  I don't remember which one.   Hm... Yes:

- ?
  I don't remember the name, but it's compiling both C and C++ code,
  which results in loading twice `[FPFX=CXX]depend2.test', which
  results in *two* definitions of CXXDEPMODE, which my revamping of
  variables now rejects.  The question is whether this double
  definition is really meant (shouldn't one of the CXX be C?).

I left these failures on purpose, but once decisions made, it's easy
to solve.



I have a question: what is the version of Perl we can require.  There
are feature implemented in 5.6 that I would like to use, but is it
acceptable?  More specifically I'm using Class::Struct which was
significantly improved since 5.005, but its only requirement is:

use 5.005_64;

so we can use it with Perl 5.5, provided that we distribute it
(Hm... is it valid wrt licenses?).  Requiring 5.6 is simpler though.
But if unacceptable, what would you say of using 5.6's Class::Struct?