Nabble - Gnu - Autoconf - General

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T10:54:13Z

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

According to Rasmus Lerdorf on 11/28/2009 11:34 AM:
> I may have spoken too soon. Someone is now reporting that with 2.62 he
> is getting:
>
> configure.in:12: error: m4_defn: undefined macro: _m4_divert_diversion
> autom4te: /usr/bin/m4 failed with exit status: 1
>
> 12: AC_PRESERVE_HELP_ORDER
> 13: AC_INIT(README.SVN-RULES)

AC_PRESERVE_HELP_ORDER must come after AC_INIT.

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

iEYEARECAAYFAksRcdUACgkQ84KuGfSFAYBkRACfdG5NQC6IlkSukxgzUOH9ZXXT
CekAoLxL5OuBazwxmWeHnQEMov6qiMkJ
=/3LW
-----END PGP SIGNATURE-----

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T10:34:09Z

I may have spoken too soon. Someone is now reporting that with 2.62 he
is getting:

configure.in:12: error: m4_defn: undefined macro: _m4_divert_diversion
autom4te: /usr/bin/m4 failed with exit status: 1

where the top of configure.in contains:

...
6: sinclude(Zend/acinclude.m4)
...
11: AC_PREREQ(2.60)
12: AC_PRESERVE_HELP_ORDER
13: AC_INIT(README.SVN-RULES)

-Rasmus

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T09:47:39Z

Eric Blake wrote:
> It appears that you are asking for a way to make all --help output appear
> in the same order in which you generate it, and to be able to intersperse
> text strings of your choosing in between strings generated by AC_ARG_WITH
> and AC_ARG_ENABLE.
>
> First, it looks like you need to use AC_PRESERVE_HELP_ORDER (added in
> 2.59c, so it will work for 2.65 but won't help you for 2.59 proper, but if
> that's the least of your worries, I can still help you with backporting it
> to 2.59 if you aren't willing to jump all the way to modern autoconf).

Aha. If I get rid of all the divert() calls and add:

AC_PREREQ(2.60)
AC_PRESERVE_HELP_ORDER

Things are looking sane. That doesn't work in 2.13, of course, but I
guess it would be a lot simpler to just leave that for older versions
and force people to upgrade for newer ones.

-Rasmus

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T07:54:14Z

On Sat, 28 Nov 2009, Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Thomas Dickey on 11/28/2009 8:40 AM:
>> well, in my view, not bothering to research a detail to provide an
>> accurate reply falls short of professional behavior.
>
> You get the level of support that you pay for. I need a more compelling
> reason to look at 2.13 than name-calling. After all:

no point in arguing. I expect that your standards are applied to each of
your endeavors.

People with more than one set of standards have no standards at all.

awai

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T07:51:16Z

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

According to Thomas Dickey on 11/28/2009 8:40 AM:
> well, in my view, not bothering to research a detail to provide an
> accurate reply falls short of professional behavior.

You get the level of support that you pay for. I need a more compelling
reason to look at 2.13 than name-calling. After all:

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

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

iEYEARECAAYFAksRRvQACgkQ84KuGfSFAYArfwCdGPPFO+dEEiG0D8NuziVxxhDl
UYwAn0hizYYeuaIHQomAHxmjK13QWFBR
=uSWg
-----END PGP SIGNATURE-----

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T07:49:11Z

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

According to Rasmus Lerdorf on 11/28/2009 8:23 AM:

>> But again, what's wrong with the
>> documented interfaces, or what is a specific example of a particular
>> string that outputs in a different location in the --help output than
>> where you want?
>
> We probably hold the world record for the most configure switches, so in
> order to make it somewhat plausible to figure them all out, we
> categorized them. The help output from 2.13 looks like this:
>
> http://lerdorf.com/c.txt
>
> Getting the TSRM switches to show up under the TSRM section in 2.59+
> isn't working, for example.

Now we're getting somewhere. From that file:

> --enable-zend-multibyte Compile with zend multibyte support
>
> TSRM:
>
> --with-tsrm-pth[=pth-config]
> Use GNU Pth

It appears that you are asking for a way to make all --help output appear
in the same order in which you generate it, and to be able to intersperse
text strings of your choosing in between strings generated by AC_ARG_WITH
and AC_ARG_ENABLE.

First, it looks like you need to use AC_PRESERVE_HELP_ORDER (added in
2.59c, so it will work for 2.65 but won't help you for 2.59 proper, but if
that's the least of your worries, I can still help you with backporting it
to 2.59 if you aren't willing to jump all the way to modern autoconf).

Then, at the place where you want TSRM: to appear (so probably just after
you did AC_ARG_ENABLE([zend-multibyte],...), but before
AC_ARG_WITH([tsrm-pth],...)), use:

m4_divert_text([HELP_ENABLE],
[AS_ECHO(["
TSRM:
"])])

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

iEYEARECAAYFAksRRnYACgkQ84KuGfSFAYAh/QCfeUaouMwPAEnaH8/oKQ0zMLLZ
niIAoMtnLKe4qNuga+jVUDrBx8MK4ZCF
=E5Nq
-----END PGP SIGNATURE-----

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T07:40:33Z

On Sat, 28 Nov 2009, Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Thomas Dickey on 11/28/2009 8:26 AM:
>> For more recent changes, one would assume you knew offhand the history.
>>
>>> autoconf, and I have no interest in trying to make it work). But, on the
>>
>> that comment doesn't sound as if you looked at 2.13 before answering.
>
> Exactly. I haven't bothered to dig up 2.13, because it is morally
> equivalent to digging up hacks needed to make K&R compilers work - so
> anachronistic and/or obsolete, that it isn't worth my time.

well, in my view, not bothering to research a detail to provide an
accurate reply falls short of professional behavior.

awai

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T07:38:11Z

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

According to Thomas Dickey on 11/28/2009 8:26 AM:
> For more recent changes, one would assume you knew offhand the history.
>
>> autoconf, and I have no interest in trying to make it work). But, on the
>
> that comment doesn't sound as if you looked at 2.13 before answering.

Exactly. I haven't bothered to dig up 2.13, because it is morally
equivalent to digging up hacks needed to make K&R compilers work - so
anachronistic and/or obsolete, that it isn't worth my time.

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

iEYEARECAAYFAksRQ+MACgkQ84KuGfSFAYAg0gCgqoTcR7cP8TIY3XOdw2Xp9JOB
xcMAn1CX/PsuvTLUVWEsOBcpYpXieaOY
=mUha
-----END PGP SIGNATURE-----

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T07:26:58Z

On Sat, 28 Nov 2009, Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Rasmus Lerdorf on 11/28/2009 6:42 AM:
>> Basically the diversions are there to organize the phases of the checks.
>> From
>> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/configure.in?view=markup
>>
>> ## Diversion 1 is the autoconf + automake setup phase. We also
>> ## set the PHP version, deal with platform-specific compile
>> ## options and check for the basic compile tools.
>
> Here's a thought. I'm not sure whether the divert's were necessary in
> autoconf 2.13 (that is so old that it pre-dates my involvement with

2.13 uses diverts for help-messages, etc.

2.5x added more, later as part of duplicating the text with/without the
--enable/--disable stuff.

For more recent changes, one would assume you knew offhand the history.

> autoconf, and I have no interest in trying to make it work). But, on the

that comment doesn't sound as if you looked at 2.13 before answering.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T07:23:12Z

Eric Blake wrote:> configure --help output is a special case where
diversion magic is

> necessary. Using diversion BODY is too late. But what's wrong with using
> the documented AC_ARG_ENABLE and AC_ARG_WITH, which properly manage the
> diversions on your behalf? Under the hood, they are using
> m4_divert_text([HELP_ENABLE], [text]) or m4_divert_text([HELP_WITH]) to
> output text into the --help stream. So technically, if you needed to use
> these (intentionally undocumented) named diversions, you could likewise
> impact the --help output. Reading lib/autoconf/general.m4 to learn about
> named diversions may be useful. But again, what's wrong with the
> documented interfaces, or what is a specific example of a particular
> string that outputs in a different location in the --help output than
> where you want?

We probably hold the world record for the most configure switches, so in
order to make it somewhat plausible to figure them all out, we
categorized them. The help output from 2.13 looks like this:

http://lerdorf.com/c.txt

Getting the TSRM switches to show up under the TSRM section in 2.59+
isn't working, for example.

-Rasmus

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T07:18:44Z

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

According to Rasmus Lerdorf on 11/28/2009 6:42 AM:
> Basically the diversions are there to organize the phases of the checks.
> From
> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/configure.in?view=markup
>
> ## Diversion 1 is the autoconf + automake setup phase. We also
> ## set the PHP version, deal with platform-specific compile
> ## options and check for the basic compile tools.

Here's a thought. I'm not sure whether the divert's were necessary in
autoconf 2.13 (that is so old that it pre-dates my involvement with
autoconf, and I have no interest in trying to make it work). But, on the
premise that they were needed back then, but are causing problems now, why
not just:

AC_DEFUN([PHP_DIVERT],[
ifdef([AC_AUTOCONF_VERSION], [],
[
divert($1)
])
])

that is, only use the divert for the autoconf version that required the
divert.

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

iEYEARECAAYFAksRP1MACgkQ84KuGfSFAYCuqwCeKvLriJcUOso4GFVhNMO9BJYf
xBAAoNaeyIIGrmw/Y1+fxOCiQIfraCbP
=fVgb
-----END PGP SIGNATURE-----

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T06:28:11Z

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

According to Rasmus Lerdorf on 11/28/2009 6:42 AM:
> Basically the diversions are there to organize the phases of the checks.
> From
> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/configure.in?view=markup
>
> ## Diversion 1 is the autoconf + automake setup phase. We also
> ## set the PHP version, deal with platform-specific compile
> ## options and check for the basic compile tools.

Autoconf itself now uses multiple diversions under the hood for setup, and
you cannot assume which diversion number is in use. You can use named
diversions to ease the pain. The named diversion BODY is (currently)
equivalent to 1000; that is the diversion that is used if you don't use
m4_divert at all. But WHY do you need diversions in the first place?
Looking at the above link, EVERY one of the diversions occurs in textual
order, meaning there is NO rearranging of the output text. So everything
you do will occur in the SAME order even if you don't play with raw
diversions (unless I'm missing some diverts that you are using in
secondary files being used with sinclude).

>
> ## Diversion 2 is the initial checking of OS features, programs,
> ## libraries and so on.
>
> ## In diversion 3 we check for compile-time options to the PHP
> ## core and how to deal with different system dependencies.
> ## This includes whether debugging or short tags are enabled
> ## and the default behaviour of php.ini options.
> ## This is also where a SAPI interface is selected (choosing between
> ## Apache module, CGI etc.)
>
> ## In diversion 4 we check user-configurable general settings.
>
> ## In diversion 5 we check which extensions should be compiled.
> ## All of these are normally in the extension directories.
> ## Diversion 5 is the last one. Here we generate files and clean up.
>
> I changed these from 1-5 to 1001-1005, but that breaks the build under
> 2.13 and even under 2.65 it messes up the output of configure --help

configure --help output is a special case where diversion magic is
necessary. Using diversion BODY is too late. But what's wrong with using
the documented AC_ARG_ENABLE and AC_ARG_WITH, which properly manage the
diversions on your behalf? Under the hood, they are using
m4_divert_text([HELP_ENABLE], [text]) or m4_divert_text([HELP_WITH]) to
output text into the --help stream. So technically, if you needed to use
these (intentionally undocumented) named diversions, you could likewise
impact the --help output. Reading lib/autoconf/general.m4 to learn about
named diversions may be useful. But again, what's wrong with the
documented interfaces, or what is a specific example of a particular
string that outputs in a different location in the --help output than
where you want?

>
> I would love to get off of 2.13, but it would be easier to do if I had a
> migration phase where things worked in both.

Good luck with that. 2.13 is so old, that it may be easier to not try
this approach, and just bite the bullet and use the newer release. Ask
the gcc folks how they did their conversion from 2.13 to 2.5x.

> As far as my little naiive attempt at replacing my divert() calls with a
> little macro that will use different diversions in 2.65 go, changing it
> to use m4_divert() didn't make a difference. And I don't really
> understand how I messed up the diversion stack.

The diversion stack tracks which diversion you were in. After AC_INIT,
the stack looks like:

KILL (aka -1)
BODY (aka 1000)

calling m4_divert(1001) is the equivalent of calling
m4_divert_pop()m4_divert_push(1001), leaving the stack at:

KILL
1001

But autoconf expects the stack to be on BODY when you exit. Since 1001 is
not BODY, you have broken the stack behind autoconf's back.

> Why does that change the stack? Shouldn't it still be pushing those
> diversions onto the stack in exactly the same order or is there some m4
> scoping thing going on?

You should consider using m4_divert_push/m4_divert_pop rather than
m4_divert; but if you must use m4_divert, then remember to change
m4_divert back to the diversion that was in use before you started
changing diversions behind autoconf's back. Also, you may be interested
in m4_divert_text, which is a friendlier wrapper that automatically puts
text in the right diversion, then restores the diversion stack.

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

iEYEARECAAYFAksRM3sACgkQ84KuGfSFAYC8VQCg1NePCMfjRRW0xu0NlM3pTiHI
AtcAoKTxXRCfk6HbOW7hkeyhwm7KKVy3
=yPZm
-----END PGP SIGNATURE-----

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T05:42:38Z

Eric Blake wrote:
> What exactly are you trying to accomplish? Without knowing your end goal,
> I can't properly suggest a better alternative (and note that the better
> alternative might mean using a different interface altogether). It may be
> better off to use the documented interface of m4_divert_text or a proper
> use of AC_REQUIRE to cause the topological sorting necessary to achieve
> your desired output order, without having to rely on raw diversions.

Basically the diversions are there to organize the phases of the checks.
From
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/configure.in?view=markup

## Diversion 1 is the autoconf + automake setup phase. We also
## set the PHP version, deal with platform-specific compile
## options and check for the basic compile tools.

## Diversion 2 is the initial checking of OS features, programs,
## libraries and so on.

## In diversion 3 we check for compile-time options to the PHP
## core and how to deal with different system dependencies.
## This includes whether debugging or short tags are enabled
## and the default behaviour of php.ini options.
## This is also where a SAPI interface is selected (choosing between
## Apache module, CGI etc.)

## In diversion 4 we check user-configurable general settings.

## In diversion 5 we check which extensions should be compiled.
## All of these are normally in the extension directories.
## Diversion 5 is the last one. Here we generate files and clean up.

I changed these from 1-5 to 1001-1005, but that breaks the build under
2.13 and even under 2.65 it messes up the output of configure --help

I would love to get off of 2.13, but it would be easier to do if I had a
migration phase where things worked in both. As it is there is a strong
faction that is of the opinion that everything works fine in 2.13, and
it all breaks in 2.65, so we'll just stick to 2.13 forever since
fiddling with m4 scripts isn't a whole lot of fun.

As far as my little naiive attempt at replacing my divert() calls with a
little macro that will use different diversions in 2.65 go, changing it
to use m4_divert() didn't make a difference. And I don't really
understand how I messed up the diversion stack. All I am doing is
replacing a direct call to divert(1) with a call to PHP_DIVERT(1) where
PHP_DIVERT is now:

AC_DEFUN([PHP_DIVERT],[
ifdef([AC_AUTOCONF_VERSION],
[
m4_case([$1],
[1],[m4_divert(1001)],
[2],[m4_divert(1002)],
[3],[m4_divert(1003)],
[4],[m4_divert(1004)],
[5],[m4_divert(1005)])
],
[
m4_divert($1)
])
])

Why does that change the stack? Shouldn't it still be pushing those
diversions onto the stack in exactly the same order or is there some m4
scoping thing going on?

-Rasmus

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

Re: regression in autoconf 2.65 ?

2009-11-28T05:02:36Z

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

According to Vincent Torri on 11/27/2009 3:26 PM:
> AC_DEFUN([EVAS_CHECK_IMAGE_LOADER],
> [
>
> m4_pushdef([UP], m4_toupper([[$1]]))
> m4_pushdef([DOWN], m4_tolower([[$1]]))

See my other mail - the quoting of m4_toupper changed, so losing the extra
layer of quotes will probably resolve this issue, too.

> AC_MSG_CHECKING([whether to enable $1 image loader])
> AC_MSG_RESULT([${want_loader}])

Stylistic point - it is simpler to use $want_loader rather than
${want_loader} in this case. And there are some places in autoconf code
where indirection requires the former instead of the latter (for example,
in config.log, autoconf decides whether to expand or escape $ sequences
when outputting a line about what is about to be executed); in those
cases, autoconf will expand $want_loader, but refuses to expand anything
containing "${" because it would be unsafe to attempt expansion of
${foo-`command`}.

> if test "x${want_loader}" = "xyes" -o "x${want_loader}" = "xstatic" -o
> "x${want_loader}" = "xauto"; then

Portability bug. Not all shells support test -o. And on those that do,
you risk failure if one of the strings being compared looks like an
operator recognized by test. The manual recommends that you write this as:

if test "x$want_loader" = xyes || test "x$want_loader" = xstatic \
|| test "x$want_loader" = xauto; then

> if test "x${have_dep}" = "xyes" ; then
> m4_default([$3], [:])
> else
> m4_default([$4], [:])
> fi

This could be written as AS_IF([test "x$have_dep" = xyes], [$3], [$4]) to
be more compact (and to avoid an unused branch of the if, when $4 is empty).

> Is it a problem in the m4 code (then older autoconf were less strict) ?
> Or is it a problem in the 2.65 version of autoconf ?

Rather, a documented change in semantics of m4_toupper in autoconf 2.65.

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

iEYEARECAAYFAksRH2wACgkQ84KuGfSFAYD+GwCfdZvQIa3YTu6fgKbdrnxl9PEg
E34AoKK7lIHH5jdQw2JZbgpM9RIV/v/A
=L0iH
-----END PGP SIGNATURE-----

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

Re: regression in autoconf 2.65 ?

2009-11-28T04:51:26Z

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

According to Vincent Torri on 11/28/2009 2:22 AM:
> AC_DEFUN([ECORE_CHECK_MODULE],
> [
> m4_pushdef([UP], m4_toupper([[$1]]))dnl
> m4_pushdef([DOWN], m4_tolower([[$1]]))dnl

Lose the extra quotes. Per the NEWS, m4_toupper and m4_tolower now
properly quote their expansion. So you need:

m4_pushdef([UP], m4_toupper([$1]))dnl
m4_pushdef([DOWN], m4_tolower([$1]))dnl

and everything else should fall into place. For example,

>
> have_ecore_[]m4_defn([DOWN])=no

with the extra quotes, this line was producing
have_ecore_foo[foo]=no
instead of the intended
have_ecore_foo=no

Sorry that this is a backwards-incompatible change, but we did document
it, and it makes m4_toupper more consistent with other m4sugar text
manipulation macros, in that it does not spuriously cause macro expansion
of the resulting text if the case-change happens to name an existing macro.

In order to write a configure.ac script that will work with both 2.64 and
younger, and with 2.65, you will need a wrapper function. Here's one way
to write it:

m4_pushdef([AAA],[BBB])dnl
m4_if(m4_toupper([aaa]),[BBB],
[m4_define([my_toupper],[m4_toupper([[$1]])])],
[m4_copy([m4_toupper], [my_toupper])])
m4_popdef([AAA])

and likewise for m4_tolower; then use my_toupper instead of m4_toupper.

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

iEYEARECAAYFAksRHM4ACgkQ84KuGfSFAYCRowCfexlfAt/MutExPK+254LDe2lR
GaMAoK7548FrWALelGWdeD0o9MQUe1CI
=SoNg
-----END PGP SIGNATURE-----

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

Re: Quick divert() 2.13/2.6x portability macro

2009-11-28T04:42:32Z

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

According to Rasmus Lerdorf on 11/28/2009 12:35 AM:
> Having plenty of problems getting our old 2.13-based autoconf setup
> working under the new diversions in 2.6

There is no version 2.6, but there is 2.65.

What exactly are you trying to accomplish? Without knowing your end goal,
I can't properly suggest a better alternative (and note that the better
alternative might mean using a different interface altogether). It may be
better off to use the documented interface of m4_divert_text or a proper
use of AC_REQUIRE to cause the topological sorting necessary to achieve
your desired output order, without having to rely on raw diversions.

> AC_DEFUN([PHP_DIVERT],[
> ifdef([AC_AUTOCONF_VERSION],
> [
> m4_case([$1],
> [1],[divert(1001)],

Use of m4_divert is better than plain divert, in that it makes it obvious
that you are using a known m4 macro. But using m4_divert at all is
generally asking for problems. Also, I'm nearly complete with a patch for
the next autoconf that will complain loudly if you use a raw number
instead of a named diversion (and the manual will probably not document
how to create named diversions, so you would have to read the source code
for that).

> configure.in:4: error: m4_divert_pop(GROW): diversion mismatch:
> configure.in:4: m4_divert: 1001
> ../../lib/m4sugar/m4sugar.m4:3251: m4_divert_push: KILL
> autom4te: /usr/bin/m4 failed with exit status: 1

Have you read this thread yet?
http://lists.gnu.org/archive/html/bug-autoconf/2009-11/msg00045.html
http://lists.gnu.org/archive/html/bug-autoconf/2009-11/msg00057.html

That error message is symptomatic of breaking the diversion stack behind
autoconf's back. In other words, autoconf expected to be in the GROW
diversion, but instead found itself in diversion 1001. It may be possible
to avoid that error with a well-placed m4_divert([GROW]) before the end of
your file, but I can't even guarantee that that will give your desired
output ordering without seeing how you are using PHP_DIVERT.

> There must be a better way to map 2.13 behaviour to 2.6. Has anybody
> tackled this?

I don't know what behavior you were expecting in 2.13, but that is so old
and interfaces have changed so much since then, including several bug
fixes, which, when not fixed, could lead to the silent output of an
invalid script for the majority of configure.ac that did not directly use
m4_divert in the first place. Personally, I won't maintain compatibility
with anything older than 2.59; 2.13 is so old that it is not worth even
trying to make a configure.ac still work with something that old. Since
m4_divert is already documented as a seldom-needed interface, I had no
qualms about making it more robust, even though it caused regressions for
the few people that were previously using it in an unsafe manner. The
number of configure.ac that directly played with diversions is small
(perhaps PHP was the only culprit). I'd like to help you fix that
breakage, but I can't/won't fix it until I know why the use of explicit
diversion management seems to be the only way to achieve your end goal.

The current manual states that playing with diversions is dangerous (it's
better to use AC_REQUIRE or m4_divert_text to a known diversion to
accomplish those goals instead), and I'm still working on a patch to make
the manual even more explicit that use of m4_divert without proper
maintenance of the diversion stack is discouraged, and that calling ANY
autoconf macro while the diversion stack is not in its usual state is
risking syntax errors in the resulting script.

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

iEYEARECAAYFAksRGrgACgkQ84KuGfSFAYDT/QCfeX2JaHPs1wC8NPw7zdVp3S2H
aWQAoI+vOcl0naYbQ/LRSmEghN23LHfP
=BdIi
-----END PGP SIGNATURE-----

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

Re: regression in autoconf 2.65 ?

2009-11-28T01:22:34Z

Hey

another simpler example of m4 macro that fails with autoconf 2.65.

Error:

configure.ac:791: error: AC_SUBST: `ecore_[job]_cflags' is not a valid shell variable name
m4/ecore_check_module.m4:2: ECORE_CHECK_MODULE is expanded from...

Call:

ECORE_CHECK_MODULE([Job], [${want_ecore_job}])

Macro:

AC_DEFUN([ECORE_CHECK_MODULE],
[
m4_pushdef([UP], m4_toupper([[$1]]))dnl
m4_pushdef([DOWN], m4_tolower([[$1]]))dnl

have_ecore_[]m4_defn([DOWN])=no
ecore_[]m4_defn([DOWN])[]_cflags=
ecore_[]m4_defn([DOWN])[]_libs=
want_module=$2

AC_ARG_ENABLE(ecore-[]m4_defn([DOWN]),
[AC_HELP_STRING(
[--enable-ecore-[]m4_defn([DOWN])],
[enable the ecore_]m4_defn([DOWN])[ module. [[default=disabled]]])],
[want_module=$enableval],
[want_module=no])

AC_MSG_CHECKING([whether ecore_]m4_defn([DOWN])[ module is to be built])

if test "x${want_module}" = "xyes" ; then
if test "x$3" = "x" -o "x$3" = "xyes" ; then
AC_DEFINE([BUILD_ECORE_]m4_defn([UP]), [1], [Build Ecore_$1 Module])
have_ecore_[]m4_defn([DOWN])="yes"
ecore_[]m4_defn([DOWN])[]_libs="-lecore_[]m4_defn([DOWN])"
AC_MSG_RESULT([yes])
else
AC_MSG_RESULT([no (dependency failed)])
fi
else
AC_MSG_RESULT([no])
fi

AM_CONDITIONAL([BUILD_ECORE_]UP, [test "x$have_ecore_]DOWN[" = "xyes"])

if test "x$have_ecore_[]m4_defn([DOWN])" = "xyes" ; then
m4_default([$4], [:])
else
m4_default([$5], [:])
fi

AC_SUBST(ecore_[]m4_defn([DOWN])[]_cflags)
AC_SUBST(ecore_[]m4_defn([DOWN])[]_libs)

m4_popdef([UP])
m4_popdef([DOWN])
])

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

Quick divert() 2.13/2.6x portability macro

2009-11-27T23:35:01Z

Having plenty of problems getting our old 2.13-based autoconf setup
working under the new diversions in 2.6

I tried an initial naiive approach of simply wrapping divert in a
version check like this:

AC_DEFUN([PHP_DIVERT],[
ifdef([AC_AUTOCONF_VERSION],
[
m4_case([$1],
[1],[divert(1001)],
[2],[divert(1002)],
[3],[divert(1003)],
[4],[divert(1004)],
[5],[divert(1005)])
],
[
divert($1)
])
])

Under 2.13 it seems happy enough with it, but with 2.64 I get:

configure.in:4: error: m4_divert_pop(GROW): diversion mismatch:
configure.in:4: m4_divert: 1001
../../lib/m4sugar/m4sugar.m4:3251: m4_divert_push: KILL
autom4te: /usr/bin/m4 failed with exit status: 1

There must be a better way to map 2.13 behaviour to 2.6. Has anybody
tackled this?

-Rasmus

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

regression in autoconf 2.65 ?

2009-11-27T14:26:44Z

Hey,

one of our configure script fails with autoconf 2.65 while it does not
with previous versions. The error is:

./configure: line 24198: syntax error near unexpected token `edb,'
./configure: line 24198: ` EVAS_CHECK_LOADER_DEP_EDB(edb, ${want_loader}, have_loader="yes", have_loader="no")'

The macro EVAS_CHECK_LOADER_DEP_EDB() is called indirectly. In
configure.ac :

EVAS_CHECK_IMAGE_LOADER([Edb], [${want_evas_image_loader_edb}])

The EVAS_CHECK_IMAGE_LOADER() macro is defined in an m4 file:

[code]

dnl use: EVAS_CHECK_IMAGE_LOADER(loader, want_loader)

AC_DEFUN([EVAS_CHECK_IMAGE_LOADER],
[

m4_pushdef([UP], m4_toupper([[$1]]))
m4_pushdef([DOWN], m4_tolower([[$1]]))

want_loader="$2"
want_static_loader="no"
have_loader="no"
have_evas_image_loader_[]DOWN="no"

AC_ARG_ENABLE([image-loader-[]DOWN],
[AC_HELP_STRING([--enable-image-loader-[]DOWN], [enable $1 image loader])],
[
if test "x${enableval}" = "xyes" ; then
want_loader="yes"
else
if test "x${enableval}" = "xstatic" ; then
want_loader="static"
else
want_loader="no"
fi
fi
]
)

AC_MSG_CHECKING([whether to enable $1 image loader])
AC_MSG_RESULT([${want_loader}])

if test "x${want_loader}" = "xyes" -o "x${want_loader}" = "xstatic" -o "x${want_loader}" = "xauto"; then
m4_default([EVAS_CHECK_LOADER_DEP_]m4_defn([UP]))(DOWN, ${want_loader}, [have_loader="yes"], [have_loader="no"])
fi

if test "x${have_loader}" = "xno" -a "x${want_loader}" = "xyes" -a "x${use_strict}" = "xyes" ; then
AC_MSG_ERROR([$1 dependencies not found (strict dependencies checking)])
fi

AC_MSG_CHECKING([whether $1 image loader will be built])
AC_MSG_RESULT([${have_loader}])

if test "x${have_loader}" = "xyes" ; then
if test "x${want_loader}" = "xstatic" ; then
have_evas_image_loader_[]DOWN="static"
want_static_loader="yes"
else
have_evas_image_loader_[]DOWN="yes"
fi
fi

if test "x${have_loader}" = "xyes" ; then
AC_DEFINE(BUILD_LOADER_[]UP, [1], [UP Image Loader Support])
fi

AM_CONDITIONAL(BUILD_LOADER_[]UP, [test "x${have_loader}" = "xyes"])

if test "x${want_static_loader}" = "xyes" ; then
AC_DEFINE(EVAS_STATIC_BUILD_[]UP, [1], [Build $1 image loader inside libevas])
have_static_module="yes"
fi

AM_CONDITIONAL(EVAS_STATIC_BUILD_[]UP, [test "x${want_static_loader}" =
"xyes"])

m4_popdef([UP])
m4_popdef([DOWN])

])

[/code]

Tha macro calls EVAS_CHECK_LOADER_DEP_EDB() which is defined in the same
m4 file:

[code]

dnl use: EVAS_CHECK_LOADER_DEP_EDB(loader, want_static[, ACTION-IF-FOUND[,
ACTION-IF-NOT-FOUND]])

AC_DEFUN([EVAS_CHECK_LOADER_DEP_EDB],
[

requirement=""
have_dep="no"
evas_image_loader_[]$1[]_cflags=""
evas_image_loader_[]$1[]_libs=""

PKG_CHECK_MODULES([EDB], [edb], [have_dep="yes" requirement="edb"],
[have_dep="no"])
evas_image_loader_[]$1[]_cflags="${EDB_CFLAGS}"
evas_image_loader_[]$1[]_libs="${EDB_LIBS}"

AC_SUBST([evas_image_loader_$1_cflags])
AC_SUBST([evas_image_loader_$1_libs])

if test "x$2" = "xstatic" ; then
requirement_evas="${requirement} ${requirement_evas}"
fi

if test "x${have_dep}" = "xyes" ; then
m4_default([$3], [:])
else
m4_default([$4], [:])
fi

])

[/code]

So I don't understand why the expansion is not done.

Is it a problem in the m4 code (then older autoconf were less strict) ? Or
is it a problem in the 2.65 version of autoconf ?

thank you

Vincent Torri

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

Re: libpthread check immature and broken

2009-11-27T10:59:11Z

Hello,

* kordex - wrote on Fri, Nov 27, 2009 at 04:16:29PM CET:
> Yes, doing the wrong thing is most likely to happen when one does not
> know the software one is trying to work with. But why does confgure
> fail even if there is -lpthread and <pthread.h> available on hpux?

Presumably (I haven't looked at the sources of the package you're trying
to build) the configure.{ac,in} simply used
AC_CHECK_LIB([pthread], [pthread_create])

which fails if pthread_create is a #define, which it is under the HP-UX
I'm looking at.

You can override the AC_CHECK_LIB test with something like
./configure ac_cv_lib_pthread_pthread_create=yes

> i
> can compile and link (and run programs) with gcc mypthread.source.c
> -lpthread . But still configure does not detect the presence of
> pthreads.

The tests from the ACX_PTHREAD macro are smart enough to cope with this
situation.

Cheers,
Ralf

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

Re: libpthread check immature and broken

2009-11-27T07:16:29Z

2009/11/27 Eric Blake <ebb9@...>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to kordex - on 11/27/2009 6:33 AM:
>> I found libpthread check broken on hpux and the cause is obvious.
>> First of all it does not include <pthread.h> second of all invoking
>> pthread_create() without arguments will cause an error. as third
>> argument pthread_create must be under main().
>
> Unfortunately, you are patching the wrong thing. configure is a generated
> script, your patch needs to touch the upstream file for things to make a
> difference. Furthermore, it looks like you are patching an AC_LINK_IFELSE
> test, whose job is to determine whether there is an external symbol named
> pthread_create that can be linked against (hence the re-declaration with
> the odd signature), and not whether it can be called properly (the test
> program being linked cannot be successfully run). If you were patching an
> AC_RUN_IFELSE test, it would make sense.
>
> - --
> 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/
>
> iEYEARECAAYFAksP1+UACgkQ84KuGfSFAYDs9gCguKpFbxbzKtaziWPkGhPh0eag
> YW8An1OBVO65v0euycLcnx0/k+XbUDTO
> =TE0K
> -----END PGP SIGNATURE-----
>

Yes, doing the wrong thing is most likely to happen when one does not
know the software one is trying to work with. But why does confgure
fail even if there is -lpthread and <pthread.h> available on hpux? i
can compile and link (and run programs) with gcc mypthread.source.c
-lpthread . But still configure does not detect the presence of
pthreads.

--Mikko

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

Re: libpthread check immature and broken

2009-11-27T07:09:15Z

2009/11/27 Philip Herron <herron.philip@...>:

> On Fri, 2009-11-27 at 15:33 +0200, kordex - wrote:
>> I found libpthread check broken on hpux and the cause is obvious.
>> First of all it does not include <pthread.h> second of all invoking
>> pthread_create() without arguments will cause an error. as third
>> argument pthread_create must be under main().
>>
>> --Mikko Kortelainen
>>
>> --- configure.old 2009-11-27 15:21:47.575062221 +0200
>> +++ configure 2009-11-27 15:21:42.230061258 +0200
>> @@ -6448,11 +6448,18 @@
>> #ifdef __cplusplus
>> extern "C"
>> #endif
>> -char pthread_create ();
>> +#include <pthread.h>
>> +void *threadfunc(void)
>> +{
>> + pthread_exit(NULL);
>> +}
>> +
>> int
>> main ()
>> {
>> -return pthread_create ();
>> + pthread_t thread;
>> + int ret = pthread_create(&thread, NULL, threadfunc, NULL);
>> + return ret;
>> ;
>> return 0;
>> }
>>
>>
>
> Are you using http://www.nongnu.org/autoconf-archive/acx_pthread.html
> ACX_PTHREAD? its been working very well for me but i haven't got access
> to any hpux to test that for you, but it works for me on linux, solaris,
> freebsd and Mac OSX I just tested this morning.
>
> --Phil
>
>

I am not using ACX_PTHEARD. I thought i would be doing the wrong
thing. This is actually xmms1 configure script which fails to detect
the presence of pthreads on hpux. I will take a look at that and if
it's possible to implement it in the current build.

--Mikko

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

Re: libpthread check immature and broken

2009-11-27T06:25:54Z

On Fri, 2009-11-27 at 15:33 +0200, kordex - wrote:

> I found libpthread check broken on hpux and the cause is obvious.
> First of all it does not include <pthread.h> second of all invoking
> pthread_create() without arguments will cause an error. as third
> argument pthread_create must be under main().
>
> --Mikko Kortelainen
>
> --- configure.old 2009-11-27 15:21:47.575062221 +0200
> +++ configure 2009-11-27 15:21:42.230061258 +0200
> @@ -6448,11 +6448,18 @@
> #ifdef __cplusplus
> extern "C"
> #endif
> -char pthread_create ();
> +#include <pthread.h>
> +void *threadfunc(void)
> +{
> + pthread_exit(NULL);
> +}
> +
> int
> main ()
> {
> -return pthread_create ();
> + pthread_t thread;
> + int ret = pthread_create(&thread, NULL, threadfunc, NULL);
> + return ret;
> ;
> return 0;
> }
>
>

Are you using http://www.nongnu.org/autoconf-archive/acx_pthread.html
ACX_PTHREAD? its been working very well for me but i haven't got access
to any hpux to test that for you, but it works for me on linux, solaris,
freebsd and Mac OSX I just tested this morning.

--Phil

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

signature.asc (204 bytes) Download Attachment

Re: libpthread check immature and broken

2009-11-27T05:45:09Z

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

According to kordex - on 11/27/2009 6:33 AM:
> I found libpthread check broken on hpux and the cause is obvious.
> First of all it does not include <pthread.h> second of all invoking
> pthread_create() without arguments will cause an error. as third
> argument pthread_create must be under main().

Unfortunately, you are patching the wrong thing. configure is a generated
script, your patch needs to touch the upstream file for things to make a
difference. Furthermore, it looks like you are patching an AC_LINK_IFELSE
test, whose job is to determine whether there is an external symbol named
pthread_create that can be linked against (hence the re-declaration with
the odd signature), and not whether it can be called properly (the test
program being linked cannot be successfully run). If you were patching an
AC_RUN_IFELSE test, it would make sense.

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

iEYEARECAAYFAksP1+UACgkQ84KuGfSFAYDs9gCguKpFbxbzKtaziWPkGhPh0eag
YW8An1OBVO65v0euycLcnx0/k+XbUDTO
=TE0K
-----END PGP SIGNATURE-----

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

libpthread check immature and broken

2009-11-27T05:33:10Z

I found libpthread check broken on hpux and the cause is obvious.
First of all it does not include <pthread.h> second of all invoking
pthread_create() without arguments will cause an error. as third
argument pthread_create must be under main().

--Mikko Kortelainen

--- configure.old 2009-11-27 15:21:47.575062221 +0200
+++ configure 2009-11-27 15:21:42.230061258 +0200
@@ -6448,11 +6448,18 @@
#ifdef __cplusplus
extern "C"
#endif
-char pthread_create ();
+#include <pthread.h>
+void *threadfunc(void)
+{
+ pthread_exit(NULL);
+}
+
int
main ()
{
-return pthread_create ();
+ pthread_t thread;
+ int ret = pthread_create(&thread, NULL, threadfunc, NULL);
+ return ret;
;
return 0;
}

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

Re: How to work around a missing library function?

2009-11-26T02:44:17Z

On Wed, Nov 25, 2009 at 19:13, Dr. David Kirkby <david.kirkby@...> wrote:

> I have some source code
>
> http://magma.maths.usyd.edu.au/~watkins/sympow.tar.bz2
>
> which will not build on an old release of HP-UX as this lacks the atoll()
> (convert string to a long long) library function.
>
> It is relatively easy to test for this in a configure script. I also found
> on the web a 10-line bit of code, which implements my_atoll()
>
> http://p2p.wrox.com/c-programming/16319-string-long-long-without-using-atoll.html
>
> in a way which works on older HP-UX releases.
>
> I'm reluctant to use this code on every OS, as its not my code, and the
> author might not like that, as this does no error checking. But it would be
> good to implement it when atoll() is not in the library.
>
> I was thinking of:
>
> 1) Changing the code from isomg atoll() to using my_atoll()
>
> 2) Having in configure.ac
>
> AC_CHECK_FUNC (atoll, [], [])
>
> 3)Having something like the following in the source code. I think the
> 'AC_CHECK_FUNC' will have defined HAVE_ATOLL, though I might be wrong on
> that.
>
>
> #ifdef HAVE_ATOLL
> long long my_atoll(char *instr){
> return atoll(instr);
> }
>
> #else
> long long my_atoll(char *instr)
> {
> long long retval;
> int i;
>
> retval = 0;
> for (; *instr; instr++) {
> retval = 10*retval + (*instr - '0');
> }
> return retval;
> }
> #fi
>
> Is it as simple as that, or am I missing something? How would that be
> improved - I somewhat doubt my method is optimal.
>

What about
AC_CHECK_FUNC (atoll, [], [AC_LIBOBJ(atoll)])
and place your atoll() implementation into atoll.c ?

Also you will need to declare prototype somewere:

#ifndef HAVE_ATOLL
long long atoll(const char *nptr);
#endif

--
Andrew W. Nosenko <andrew.w.nosenko@...>

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

Re: How to work around a missing library function?

2009-11-26T02:31:55Z

"Dr. David Kirkby" <david.kirkby@...> writes:
> The person who wrote the software is not using autoconf, but I've
> offered to convert it to autoconf, as his 'Configure' script has not
> worked well for use in the Sage project, and peoples attempts to hack
> it to work have been less than successful too.
That's of course a political question and I can feel your pain. My
recommendation is to start small, show real benefit from your changes
and if possible do one step at a time building up trust with the main
developer. As soon as you have autoolified the project, gnulib
integration should be fairly easy.

> The library had various macros, which will only complicate things. I
> really do want to keep this as simple as possible, as I fear otherwise
> he will abandon the autoconf/automake approach, and go back to his
> Configure' script, which works well for him.
Show him that an autotooled project works very well for the users on
various platforms.

HTH
Christian

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

Re: compile wrapper script with C++ file

2009-11-25T16:56:27Z

> but it still wouldn't help with MSVC: first, it *has* an /Fo$object switch

that's the problem I just ran into, after adding some extra CPPFLAGS
to a library, like

libfoo_a_CPPFLAGS=something

which leads to the result, that automake starts to compile
CL.EXE -c -o libfoo_a_foo.obj foo.c

but CL.EXE always ignores the output name and generates foo.obj.

Just replacing -o by -Fo does not work because this is only true for the
compile step (-c also given) but not for linking.

Since we already have our own CL.EXE wrapper script, we can handle this.

Of course it we would be nice, if this handling would be already done
by compile,
but there are many other issues with other compilers (i.a. armcc)
which still require
own wrappers.

Regards, Carsten

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

Re: [crazy bug] please help me

2009-11-25T16:37:16Z

> Or are there some features not working with textmode when using
> autotools? I think this could almost be expected because those
> LFs IMHO can be really painfull...

there also some issues while using autotools.
one example are linefeeds in macros, i.e.

AC_CONFIG_FILES([
x
])

will produce strange results if used with DOS linefeeds.

this makes some guys think, it might be better to mark those files as
binary in cvs and maintain it using unix linefeeds, even in a DOS
environment.

strange conclusion ... that's my experience.

> One feature with issues with LF translation is "make dist" (even
> with export CYGWIN=binmode).

this seems to be an issue of tar, because it can be avoided with the
automake option "tar-pax" (without knowing what exactly this does).

>> Use of binmode mounts means that you don't have to worry about
>> spurious carriage returns getting inserted in files by tools
>> that speak text, only to confuse tools that only speak binary.

this is exactly my experience, too. I am using binmode only since many
years without real issues.

>> Textmode mounts, on the other hand, are painful to
>> manage without a lot of care.

this is true only for some tools, not most of them. unfortunately
microsoft visual studio is one them, which is used often in
development.

but as a developper, I see no problem for handling it.

> I think with binmode mounts practically ALL (windows)
> tools fail, but of course heavily depends on the used tools.

I would say, most windows tools are able to handle linux linefeeds.
only some can't, and for me, it is no problem to avoid using them.

regards, carsten

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

Re: How to work around a missing library function?

2009-11-25T15:17:28Z

Mike Frysinger wrote:

> if you arent using autoconf, i'm not sure why you're posting to the autoconf
> list. gnulib really doesnt add any dependencies above autoconf/automake, and
> those are pretty basic as it is.
> -mike

The person who wrote the software is not using autoconf, but I've offered to
convert it to autoconf, as his 'Configure' script has not worked well for use in
the Sage project, and peoples attempts to hack it to work have been less than
successful too.

The library had various macros, which will only complicate things. I really do
want to keep this as simple as possible, as I fear otherwise he will abandon the
autoconf/automake approach, and go back to his 'Configure' script, which works
well for him.

That's my dilema.

Dave

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

Re: How to work around a missing library function?

2009-11-25T14:39:20Z

On Wednesday 25 November 2009 16:25:54 Dr. David Kirkby wrote:

> Mike Frysinger wrote:
> > On Wednesday 25 November 2009 13:43:34 Dr. David Kirkby wrote:
> >> Mike Frysinger wrote:
> >>> On Wednesday 25 November 2009 12:13:56 Dr. David Kirkby wrote:
> >>>> I'm reluctant to use this code on every OS, as its not my code, and
> >>>> the author might not like that, as this does no error checking. But it
> >>>> would be good to implement it when atoll() is not in the library.
> >>>
> >>> check out the gnulib project
> >>
> >> Thank you Mike, I will do that. I assume that will provide an
> >> implementation for atoll(). But is the rest of my logic ok?
> >
> > while your logic looked ok, you dont need to worry about it with gnulib.
> > not only does it provide atoll replacements, but it takes care of the
> > configure tests and enabling it as needed as well. your source code
> > shouldnt need to change -- it can be written to assume atoll exists.
> > it's a pretty badass project.
> > -mike
>
> A big problem is gnulib is GPL3 - I need to code to be GPL2, so I can not
> use the library.

no, specific modules have different licenses. review the license for the
specific module you wish to import, or use the --lgpl2 option to the gnulib-
tool script so it'll abort early if importing something with gpl3.

if a module you want is under gpl3 only, you can always ask to have it be
allowed under the lgpl2. it isnt an uncommon request.

> The second issue is that I am not totally convinced the person who wrote
> that code would appreciate all the dependencies of gnublib.
>
> I've suggested I convert his 'Configure' script to one which uses
> autoconf/automake. I think simplicity is needed here. I can't see him
> objecting to a few lines of C inserted, but the code in gnulib has various
> dependencies. It also calls strtoll() which does not exist, so that too
> would have to be built.
>
> The author of the code does not use autoconf/automake, but said he would my
> changes as long as he could make changes easily. I'm a bit worried he might
> just prefer his 'Configure' script anyway, which works well for him.
>
> I would like to avoid having m4 macros, and anything else that makes it
> more difficult for someone to understand.

if you arent using autoconf, i'm not sure why you're posting to the autoconf
list. gnulib really doesnt add any dependencies above autoconf/automake, and
those are pretty basic as it is.
-mike

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

signature.asc (853 bytes) Download Attachment

Re: How to work around a missing library function?

2009-11-25T13:25:54Z

Mike Frysinger wrote:

> On Wednesday 25 November 2009 13:43:34 Dr. David Kirkby wrote:
>> Mike Frysinger wrote:
>>> On Wednesday 25 November 2009 12:13:56 Dr. David Kirkby wrote:
>>>> I'm reluctant to use this code on every OS, as its not my code, and the
>>>> author might not like that, as this does no error checking. But it
>>>> would be good to implement it when atoll() is not in the library.
>>> check out the gnulib project
>> Thank you Mike, I will do that. I assume that will provide an
>> implementation for atoll(). But is the rest of my logic ok?
>
> while your logic looked ok, you dont need to worry about it with gnulib. not
> only does it provide atoll replacements, but it takes care of the configure
> tests and enabling it as needed as well. your source code shouldnt need to
> change -- it can be written to assume atoll exists. it's a pretty badass
> project.
> -mike

A big problem is gnulib is GPL3 - I need to code to be GPL2, so I can not use
the library.

The second issue is that I am not totally convinced the person who wrote that
code would appreciate all the dependencies of gnublib.

I've suggested I convert his 'Configure' script to one which uses
autoconf/automake. I think simplicity is needed here. I can't see him objecting
to a few lines of C inserted, but the code in gnulib has various dependencies.
It also calls strtoll() which does not exist, so that too would have to be built.

The author of the code does not use autoconf/automake, but said he would my
changes as long as he could make changes easily. I'm a bit worried he might just
prefer his 'Configure' script anyway, which works well for him.

I would like to avoid having m4 macros, and anything else that makes it more
difficult for someone to understand.

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

Re: How to work around a missing library function?

2009-11-25T13:08:28Z

On Wednesday 25 November 2009 13:43:34 Dr. David Kirkby wrote:

> Mike Frysinger wrote:
> > On Wednesday 25 November 2009 12:13:56 Dr. David Kirkby wrote:
> >> I'm reluctant to use this code on every OS, as its not my code, and the
> >> author might not like that, as this does no error checking. But it
> >> would be good to implement it when atoll() is not in the library.
> >
> > check out the gnulib project
>
> Thank you Mike, I will do that. I assume that will provide an
> implementation for atoll(). But is the rest of my logic ok?

while your logic looked ok, you dont need to worry about it with gnulib. not
only does it provide atoll replacements, but it takes care of the configure
tests and enabling it as needed as well. your source code shouldnt need to
change -- it can be written to assume atoll exists. it's a pretty badass
project.
-mike

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

signature.asc (853 bytes) Download Attachment

Re: How to work around a missing library function?

2009-11-25T12:35:26Z

NTP does a fair amount of providing missing library code as well - we
generally only use a package-provided copy if one is not availble from
the system.

H

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

Re: How to work around a missing library function?

2009-11-25T10:43:34Z

Mike Frysinger wrote:
> On Wednesday 25 November 2009 12:13:56 Dr. David Kirkby wrote:
>> I'm reluctant to use this code on every OS, as its not my code, and the
>> author might not like that, as this does no error checking. But it would
>> be good to implement it when atoll() is not in the library.
>
> check out the gnulib project
> -mike

Thank you Mike, I will do that. I assume that will provide an implementation for
atoll(). But is the rest of my logic ok?

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