nano-devel
[Top][All Lists]
Advanced

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

Re: [Nano-devel] [PATCH 01/10] configure: require autoconf-2.69/automake


From: Benno Schulenberg
Subject: Re: [Nano-devel] [PATCH 01/10] configure: require autoconf-2.69/automake-1.14
Date: Fri, 22 Apr 2016 21:14:13 +0200

On Mon, Apr 18, 2016, at 22:12, Mike Frysinger wrote:
> On 18 Apr 2016 21:27, Benno Schulenberg wrote:
> > On Mon, Apr 18, 2016, at 08:17, Mike Frysinger wrote:
> > > -AM_INIT_AUTOMAKE
> > > +AM_INIT_AUTOMAKE([1.14])
> > 
> > > -AC_PREREQ(2.61)
> > > +AC_PREREQ([2.69])
> > 
> > But as far as I can tell, you're not making use of any extra macros?
> 
> the issue is more that people with newer versions will start using macros
> that only exist in the newer versions, but autoconf has no mechanism for
> detecting that.  you'd have to actually run autoconf-2.61 to figure out
> which macros you were using that didn't exist in that version.

I see.  But then, if a developer would introduce the use of a newer macro,
then we'll get a bug report at some time that this doesn't work on an older
autoconf/automake, and then we'll fix that to make it work.

In my opinion it should be possible to build nano from git on a stock
installation of any stable or LTS version of a distro that is still
being maintained.

> so if we
> have no compelling reason to support those older versions, it's easier to
> just pull up the min required version to what we're actually using.

I think it should be the other way around: only up the requirements if
you actually need a newer macro.  (I know, it's hard to know whether a
macro is relatively new or not, but still.)

> for example, we currently do not list a min version for automake.  i can
> show for a fact that versions <1.7 will fail at autoreconf time.

Then specifying 1.7 as minimum for automake will be good.

> but failures can show up other ways ... at configure or make time.  so do
> we spend time testing older, or just pull up to a min ?  imo there's no
> real value in supporting versions that are many years old at this point.

The value is in being able to build nano from git on an old but still
maintained distro without needing to install anything else.

> so to flip it around, are there are any compelling scenarios we want to
> support where the person is building from the *development git* repo and
> is on a fairly old system ?

Users that want to follow the development of nano but of nothing else.


> > ./configure: line 8314: syntax error near unexpected token `NCURSESW,'
> > ./configure: line 8314: `       PKG_CHECK_MODULES(NCURSESW, ncursesw,'
> > 
> > I did have pkg-config installed, but apparently it needs some minimum
> > version?  Should the configure script not test for this, instead of choking
> > in a syntax error?
> 
> you need the development pkg-config package.  the runtime-only package
> most likely does not include the m4 file.

On that old system no dev package of pkg-config existed.
And it worked fine with the older, native auto* things.

Benno

-- 
http://www.fastmail.com - Faster than the air-speed velocity of an
                          unladen european swallow




reply via email to

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