checking automake version in configure.ac

[Vincent Torri-2]

Hey,

I would like to conditionnaly use a feature (a macro) of automake 1.11
with system that don't necessary have it installed.

So I would like to know if it is possible to check the version of automake
in configure.ac, something like

if test "$automake_version" = "1.11" ; then
  ***
fi

or something similar

thank you

Vincent Torri



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[mpsuzuki]

Hi,

I guess the reason checking automake version is
to guarantee the regeneration of configure,
Makefile.in etc. For the people who just run configure
without modification of configure.{in|ac}, Makefile.am, etc etc,
I guess you won't ask them to install automake-1.11.

If my guessing is right, the popular method would
be packing autogen.sh with version checking.

FreeType
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/autogen.sh

GLib
http://git.gnome.org/cgit/glib/tree/autogen.sh

# Usually, autogen.sh is included in the software under
# development by CVS/SVN/GIT, but it is not included in
# the released tarball.

By checking automake version out of configure.ac,
we can keep the people just running configure from
annoying message "your automake is too old, but
you can continue configuration". How do you think of?

Regards,
mpsuzuki

On Tue, 6 Oct 2009 07:56:39 +0200 (CEST)
Vincent Torri <vtorri@...> wrote:

>I would like to conditionnaly use a feature (a macro) of automake 1.11
>with system that don't necessary have it installed.
>
>So I would like to know if it is possible to check the version of automake
>in configure.ac, something like
>
>if test "$automake_version" = "1.11" ; then
>  ***
>fi
>
>or something similar
>
>thank you
>
>Vincent Torri
>
>
>
>_______________________________________________
>Autoconf mailing list
>Autoconf@...
>http://lists.gnu.org/mailman/listinfo/autoconf

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Vincent Torri-2]

Hey,

> I guess the reason checking automake version is
> to guarantee the regeneration of configure,
> Makefile.in etc. For the people who just run configure
> without modification of configure.{in|ac}, Makefile.am, etc etc,
> I guess you won't ask them to install automake-1.11.
>
> If my guessing is right, the popular method would
> be packing autogen.sh with version checking.

we actually pack autogen.sh. Checking the version of automake in it and
use it in configure.ac is indeed a solution.

Is there a better one ?

thanks

Vincent Torri


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Corsepius-2]

On 10/06/2009 08:49 AM, Vincent Torri wrote:

> Is there a better one ?
Add the minimum version of automake required to _rebuild_ the automake
generated to the option passed to AM_INIT_AUTOMAKE.

AM_INIT_AUTOMAKE([1.11])

This way, running an insufficient automake on your source files will
error out.

Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Vincent Torri-2]

On Tue, 6 Oct 2009, Ralf Corsepius wrote:

> On 10/06/2009 08:49 AM, Vincent Torri wrote:
>
>> Is there a better one ?
> Add the minimum version of automake required to _rebuild_ the automake
> generated to the option passed to AM_INIT_AUTOMAKE.
>
> AM_INIT_AUTOMAKE([1.11])

yes, but...

> This way, running an insufficient automake on your source files will error
> out.

... I don't want that behavior. I just want to add a feature, not to
forbid a user to rebuild the files.

Vincent Torri


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Corsepius-2]

On 10/06/2009 09:43 AM, Vincent Torri wrote:

>
>
> On Tue, 6 Oct 2009, Ralf Corsepius wrote:
>
>> On 10/06/2009 08:49 AM, Vincent Torri wrote:
>>
>>> Is there a better one ?
>> Add the minimum version of automake required to _rebuild_ the
>> automake generated to the option passed to AM_INIT_AUTOMAKE.
>>
>> AM_INIT_AUTOMAKE([1.11])
>
> yes, but...
>
>> This way, running an insufficient automake on your source files will
>> error out.
>
> ... I don't want that behavior. I just want to add a feature, not to
> forbid a user to rebuild the files.

Your consideration doesn't make sense.

If your package requires a minimum version of automake, then your
package can't be rebuilt without a sufficient version of automake,
therefore the user must be stopped running his automake.

Ralf





_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Corsepius on 10/6/2009 1:45 AM:

>>> AM_INIT_AUTOMAKE([1.11])
>>
>> yes, but...
>>
>>> This way, running an insufficient automake on your source files will
>>> error out.
>>
>> ... I don't want that behavior. I just want to add a feature, not to
>> forbid a user to rebuild the files.
> Your consideration doesn't make sense.
>
> If your package requires a minimum version of automake, then your
> package can't be rebuilt without a sufficient version of automake,
> therefore the user must be stopped running his automake.

The desired behavior TOTALLY makes sense (although this is an automake
question, not an autoconf question) - an example is the use of color-tests
when available, with a clean fallback to no color-tests if an older
automake was sufficient for everything else.  See this thread on the
automake list for the same question, and the answer given by the maintainer:
http://lists.gnu.org/archive/html/automake/2009-08/msg00035.html
http://lists.gnu.org/archive/html/automake/2009-08/msg00040.html

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrLMMsACgkQ84KuGfSFAYB0iwCeMvx6wdGc3BDm7mUGQ4dwGE+/
054An3wYsXGwULMIy7LToFv0IJrem1Kr
=xYCX
-----END PGP SIGNATURE-----


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Vincent Torri-2]

On Tue, 6 Oct 2009, Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Ralf Corsepius on 10/6/2009 1:45 AM:
>>>> AM_INIT_AUTOMAKE([1.11])
>>>
>>> yes, but...
>>>
>>>> This way, running an insufficient automake on your source files will
>>>> error out.
>>>
>>> ... I don't want that behavior. I just want to add a feature, not to
>>> forbid a user to rebuild the files.
>> Your consideration doesn't make sense.
>>
>> If your package requires a minimum version of automake, then your
>> package can't be rebuilt without a sufficient version of automake,
>> therefore the user must be stopped running his automake.
>
> The desired behavior TOTALLY makes sense (although this is an automake
> question, not an autoconf question)

sorry for that. Actually, i wondered to which list i had to send the
question.

> - an example is the use of color-tests
> when available, with a clean fallback to no color-tests if an older
> automake was sufficient for everything else.  See this thread on the
> automake list for the same question, and the answer given by the maintainer:
> http://lists.gnu.org/archive/html/automake/2009-08/msg00035.html
> http://lists.gnu.org/archive/html/automake/2009-08/msg00040.html

so:

m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])

seems the thing to do.

Thank you

Vincent Torri


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Corsepius]

On 10/06/2009 01:58 PM, Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Ralf Corsepius on 10/6/2009 1:45 AM:
>>>> AM_INIT_AUTOMAKE([1.11])
>>>
>>> yes, but...
>>>
>>>> This way, running an insufficient automake on your source files will
>>>> error out.
>>>
>>> ... I don't want that behavior. I just want to add a feature, not to
>>> forbid a user to rebuild the files.
>> Your consideration doesn't make sense.
>>
>> If your package requires a minimum version of automake, then your
>> package can't be rebuilt without a sufficient version of automake,
>> therefore the user must be stopped running his automake.
>
> The desired behavior TOTALLY makes sense (although this is an automake
> question, not an autoconf question)

 > - an example is the use of color-tests
> when available, with a clean fallback to no color-tests if an older
> automake was sufficient for everything else.

Well, this is an entirely different use-case.

This is changing the configure's behavior at configure run-time. It is
not the running "autogen.sh" (autoreconf) case.

And whether version checking is an appropriate means/good approach in
general at all, is a different question.

Ralf



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Eric Blake]

Ralf Corsepius <rc040203 <at> freenet.de> writes:

> >>> ... I don't want that behavior. I just want to add a feature, not to
> >>> forbid a user to rebuild the files.
> > The desired behavior TOTALLY makes sense (although this is an automake
> > question, not an autoconf question)
>  > - an example is the use of color-tests
> > when available, with a clean fallback to no color-tests if an older
> > automake was sufficient for everything else.
>
> Well, this is an entirely different use-case.
>
> This is changing the configure's behavior at configure run-time. It is
> not the running "autogen.sh" (autoreconf) case.

Huh?  Vincent's question was how to make an automake-time decision about
whether automake supports the silent-rules feature added in 1.11, so that on
newer developer's machines, the resulting configure will support the option of
that feature, but without penalizing older developer's machines and without
requiring the use of AM_INIT_AUTOMAKE([1.11]).  It was NOT about the configure-
time question of whether the user can turn the option on or off, given a
configure that was built with automake 1.11 with the silent-rules feature
enabled.  And even if you use automake 1.11 but choose to not enable the silent-
rules feature, the resulting configure file will not support silent rules,
since it depends on a corner case of make behavior that is not strictly POSIX
(although it appears to be portably implemented across a wide selection of make
implementations).

>
> And whether version checking is an appropriate means/good approach in
> general at all, is a different question.

m4_ifdef([AM_SILENT_RULES]) is as good as it gets - it's a feature test, which
is better than a version check.  As long as new automake features are always
given a corresponding feature check ability, then it is possible to write
configure.ac that takes advantage of the features when present without choking
when used with older automake versions.

--
Eric Blake




_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Corsepius]

On 10/06/2009 04:52 PM, Eric Blake wrote:

> Ralf Corsepius<rc040203<at>  freenet.de>  writes:
>
>>>>> ... I don't want that behavior. I just want to add a feature, not to
>>>>> forbid a user to rebuild the files.
>>> The desired behavior TOTALLY makes sense (although this is an automake
>>> question, not an autoconf question)
>>   >  - an example is the use of color-tests
>>> when available, with a clean fallback to no color-tests if an older
>>> automake was sufficient for everything else.
>>
>> Well, this is an entirely different use-case.
>>
>> This is changing the configure's behavior at configure run-time. It is
>> not the running "autogen.sh" (autoreconf) case.
>
> Huh?

Citing from the 1st and 2nd answer to this thread:

Somebody >> If my guessing is right, the popular method would
Somebody >> be packing autogen.sh with version checking.
Vincent > we actually pack autogen.sh. Checking the version of
Vincent > automake in it and use it in configure.ac is indeed
Vincent > a solution.
Vincent > Is there a better one ?

>> And whether version checking is an appropriate means/good approach in
>> general at all, is a different question.
>
> m4_ifdef([AM_SILENT_RULES]) is as good as it gets - it's a feature test, which
> is better than a version check.  As long as new automake features are always
> given a corresponding feature check ability, then it is possible to write
> configure.ac that takes advantage of the features when present without choking
> when used with older automake versions.
IMNSHO,
a) AM_SILENT_RULES are harmful (I know, you know that I think about this
(mal-) "feature" this way - Working around the issues they are causing
in Fedora packaging is a major nuissance.)

b) having them as optional feature at configure-run-time introduces
non-deterministic behavior.

Ralf




_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

[ adding automake@ ]

Hello Ralf,

* Ralf Corsepius wrote on Tue, Oct 06, 2009 at 05:49:52PM CEST:
> a) AM_SILENT_RULES are harmful (I know, you know that I think about
> this (mal-) "feature" this way - Working around the issues they are
> causing in Fedora packaging is a major nuissance.)

Could you expand on this nuisance a bit more?

What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?  This is an honest question;
I'd like to avoid extra work for distributors.

Thanks,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Corsepius]

On 10/06/2009 09:52 PM, Ralf Wildenhues wrote:

> [ adding automake@ ]
>
> Hello Ralf,
>
> * Ralf Corsepius wrote on Tue, Oct 06, 2009 at 05:49:52PM CEST:
>> a) AM_SILENT_RULES are harmful (I know, you know that I think about
>> this (mal-) "feature" this way - Working around the issues they are
>> causing in Fedora packaging is a major nuissance.)
>
> Could you expand on this nuisance a bit more?

I did so several times before.

Anyway, ...

The problem is verifying "correctness of building" packages in batches.

i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler calls
etc. for correctness

(NB: A package, which compiles without warning doesn't mean it is being
built correctly.)

> What work does it cause except for using --disable-silent-rules at
> configure time or V=1 at make time?
Exactly this is the problem.

It means automake is pushing around package maintainers to modify their
packages to automake's behavioral changes.

As many package maintainers are no autotools' specialists, this is a
non-trivial problem.

Ralf



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Bob Friesenhahn]

On Tue, 13 Oct 2009, Ralf Corsepius wrote:

>
> The problem is verifying "correctness of building" packages in batches.
>
> i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler calls etc.
> for correctness
>
> (NB: A package, which compiles without warning doesn't mean it is being built
> correctly.)
>
>> What work does it cause except for using --disable-silent-rules at
>> configure time or V=1 at make time?
> Exactly this is the problem.

The problem isn't the support for silent rules.  The problem is that
some packages are enabling it by default because it looks like Linux
and Linux is cool.  This is exactly the problem that I was concerned
about and why I fought to ensure that it is not enabled by default.
Unfortunately, it was made very easy for a package author to enable by
default and some package authors are now doing so even though it makes
open source software seem confusing and inconsistent.

> It means automake is pushing around package maintainers to modify their
> packages to automake's behavioral changes.

Quite annoying indeed.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Corsepius]

On 10/13/2009 04:49 PM, Bob Friesenhahn wrote:

> On Tue, 13 Oct 2009, Ralf Corsepius wrote:
>>
>> The problem is verifying "correctness of building" packages in batches.
>>
>> i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler
>> calls etc. for correctness
>>
>> (NB: A package, which compiles without warning doesn't mean it is
>> being built correctly.)
>>
>>> What work does it cause except for using --disable-silent-rules at
>>> configure time or V=1 at make time?
>> Exactly this is the problem.
>
> The problem isn't the support for silent rules.  The problem is that
> some packages are enabling it by default

Indeed. What makes the situation worse is some upstreams shipping
"common" aclocal-macros which enable it by default. This cause quite
some amount of surprises when analysing buildlogs of packages which for
whatever reasons run autoreconf/autogen.sh.

> because it looks like Linux and Linux is cool.
:=)

Ralf



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Corsepius on 10/13/2009 9:20 AM:
>>>> What work does it cause except for using --disable-silent-rules at
>>>> configure time or V=1 at make time?
>>> Exactly this is the problem.
>>
>> The problem isn't the support for silent rules.  The problem is that
>> some packages are enabling it by default

But YOU can still disable it by default, by writing your packaging
automation tools to supply --disable-silent-rules as part of calling
./configure, and/or writing an appropriate config.site.  In other words,
the person running ./configure STILL has the option to choose YOUR desired
default, even if it is different than the package author's desired
default.  The use of silent-rules is an option, not a mandate.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrVIjoACgkQ84KuGfSFAYBm1ACbB9ySznASW/iwTtoWtJKHjqzW
gTsAnjr5gWKg/ZwTOZCjUKZYUiS9A4jI
=hAug
-----END PGP SIGNATURE-----


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Corsepius]

On 10/14/2009 02:58 AM, Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Ralf Corsepius on 10/13/2009 9:20 AM:
>>>>> What work does it cause except for using --disable-silent-rules at
>>>>> configure time or V=1 at make time?
>>>> Exactly this is the problem.
>>>
>>> The problem isn't the support for silent rules.  The problem is that
>>> some packages are enabling it by default
>
> But YOU can still disable it by default, by writing your packaging
> automation tools to supply --disable-silent-rules as part of calling
> ./configure, and/or writing an appropriate config.site.  In other words,
> the person running ./configure STILL has the option to choose YOUR desired
> default, even if it is different than the package author's desired
> default.

Exactly what I said in a previous mail: Automake is pushing around
package maintainers to modify their packages to automake's behavioral
changes. (Here package maintainer == Package installers)

 > The use of silent-rules is an option, not a mandate.
IMO, upstream maintainers, who use silent rules, don't have much clues
about what they are doing - Their practice is harmful.



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Richard Ash-6]

On Wed, 2009-10-14 at 03:17 +0200, Ralf Corsepius wrote:

> > But YOU can still disable it by default, by writing your packaging
> > automation tools to supply --disable-silent-rules as part of calling
> > ./configure, and/or writing an appropriate config.site.  In other words,
> > the person running ./configure STILL has the option to choose YOUR desired
> > default, even if it is different than the package author's desired
> > default.
>
> Exactly what I said in a previous mail: Automake is pushing around
> package maintainers to modify their packages to automake's behavioral
> changes. (Here package maintainer == Package installers)

Or use the config.site mechanism as part of the build environment, which
means no change to the packaging automation tools, just an addition to
the build environment (which I assume you have to standardise anyway).

Richard



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf