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

[Mike Frysinger]

On 22 Apr 2016 21:14, Benno Schulenberg wrote:
> 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.

honestly, "any" is unrealistic, and nano already violates it.  when you
bumped the autoconf requirement to 2.61, that cut out RHEL4 & RHEL5 which
are both LTS and actively maintained through 2017 & 2020 -- they have are
shipping autoconf-2.59 there.  the RHEL lifetime is >10 years.  trying to
support 15+ year old devtools is a pointless exercise imnsho.

please refine this requirement to something reasonable.  no other project
i've worked on restricts themselves this way.

> > 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.

"anything else" ?  you need to install a bunch of dev packages before you
can build nano (or any other package) from source.

> > 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.

do those users actually exist ?  supporting a target that no one uses or
cares about wastes our time validating things.  if one user shows up every
other year in such a scenario, seems like grabbing the latest nano release
at that time would largely be sufficient.

> > > ./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.

it's not an autotool version issue.  if you don't have pkg-config
available, then you can't build nano.  it's been this way for about
two years now.  considering pkg-config has been around and in heavy
use for more than 5 years now, that's plenty of time to require.
-mike

signature.asc
Description: Digital signature