Jeffrey Walton wrote:
For the love of Christ, stop it with these useless version numbers.
I've never been a fan of that version-number checking either, but this is no way
to advocate change.
If you want the problem fixed, I suggest that you write a patch to the Autoconf
source code that fix
For some reason the authors like to require the latest autotools version they
have. That's wrong. They should require the lowest supported version.
25.08.2018 10:55, Paul Eggert пишет:
> Jeffrey Walton wrote:
>> For the love of Christ, stop it with these useless version numbers.
>
> I've never
Not saying this is right or wrong, but as an autoconf user - it can be hard
to know what versions support what features. So if I'm autotoolizing a
package, I would probably require whatever version I had at the time.
Are there any tools out there that will scan a configure.ac/Makefile.am and
tell
I have a VM with RHEL 6.8, because that's what our customers build our software
on. And when I change anything in configure.ac, I test it there.
Of course, such conservative attitude is unnecessary for open source projects,
but supporting four year old autotools looks reasonable.
25.08.2018 19:
On Aug 25, 2018, at 10:23 AM, Basin Ilya wrote:
>
> I have a VM with RHEL 6.8, because that's what our customers build our
> software on. And when I change anything in configure.ac, I test it there.
> Of course, such conservative attitude is unnecessary for open source
> projects, but supportin
Indeed. When considering addition of a new macro call to configure.ac
it often requires a lot of digging (usually from NEWS) to find out if
using that macro is safe with current minimum autoconf version
requirement. It would be really good if the documentation about macros
would say what version o
