You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2000/07/01 16:23:44 UTC
Re: cvs commit: apache-2.0/src/modules/dav/main config.m4
On Sat, Jul 01, 2000 at 02:08:25PM -0000, gstein@locus.apache.org wrote:
>...
> *) do endian testing, so we can feed it into Expat to optimize that code
>...
> +dnl check for endianness
> +if test "$cross_compiling" = "no"; then
> + AC_C_BIGENDIAN
> +else
> + AC_DEFINE(AP_UNKNOWN_BYTE_ORDER,1,
> + [byte order is unknown due to cross-compilation])
> +fi
With the introduction of AC_C_BIGENDIAN, ./buildconf will now issue warnings
about a missing cross-compile parameter to AC_TRY_RUN(). This warning can be
safely ignored.
Basically, it is there to let you know that AC_C_BIGENDIAN isn't going to
work in the cross-compile case. Of course, it doesn't know that we are going
to check for that (see above) before calling AC_C_BIGENDIAN which calls
AC_TRY_RUN.
We could clone AC_C_BIGENDIAN and write a custom version of this stuff, but
that feels a bit bogus (we'd lose future changes/fixes to the macro). The
right approach might be to print something in buildconf saying "this warning
is safe to ignore".
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/modules/dav/main config.m4
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Jul 02, 2000 at 01:54:52AM +0200, Sascha Schumann wrote:
> > I see nothing that we can do here except to live with it (my recommendation)
> > or to complete reimplement our own copy of AC_C_BIGENDIAN (to use
> > AC_TRY_RUN_NATIVE).
>
> PHP runs the autoconf/autoheader output through grep and
> filters the warning simply away. Not elegant, but it is
> appropiate for projects which are not intended for cross
> compilation anyway.
That works for me. I've just committed a change to do this filtering.
Unfortunately, I'm not 100% on it because we ignore tha autoconf/autoheader
status code. I'm not sure how to propagate that code across the grep
invocation.
Anybody know?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/modules/dav/main config.m4
Posted by Sascha Schumann <sa...@schumann.cx>.
> I see nothing that we can do here except to live with it (my recommendation)
> or to complete reimplement our own copy of AC_C_BIGENDIAN (to use
> AC_TRY_RUN_NATIVE).
PHP runs the autoconf/autoheader output through grep and
filters the warning simply away. Not elegant, but it is
appropiate for projects which are not intended for cross
compilation anyway.
- Sascha
Re: cvs commit: apache-2.0/src/modules/dav/main config.m4
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Jul 01, 2000 at 02:29:47PM -0700, rbb@covalent.net wrote:
>
> > > AC_TRY_RUN allows you to provide a default for this case. Just provide
> > > something intelligent, and the warning should go away. :-)
> >
> > The issue is that the AC_TRY_RUN is *inside* the AC_C_BIGENDIAN macro. We
> > can't insert a test for the third case.
> >
> > AC_C_BIGENDIAN omits the param on purpose since you can't determine the
> > target byte order if cross-compiling is occurring. (since AC_TRY_RUN
> > actually *executes* the code, which is impossible in a cross-compile setup).
> > By omitting the param on purpose, it ensures that a warning will appear for
> > the ./configure author to make sure they have covered the situation.
> >
> > In our case, we check the "cross_compiling" variable before calling into the
> > AC_C_BIGENDIAN (meaning: the person *running* configure will not have any
> > problems).
>
> I understand the issues. This is solvable however. Because we don't even
euh... see below...
> CALL the macro if we are cross compiling, just provide a relatively sane
> default to TRY_RUN. This is harmless, because this code will never be
> touched, but it will remove a warning that can potentially bother some
> people.
>
> IMNSHO, removing a warning that is meaningless by adding a USELESS
> parameter that is never used is a win in this situation.
>
> Imagine the scenario where you download the code, and try to compile
> it. The first thing you see is a warning message. Personally, this would
> scare me off a bit. We try very hard to avoid warnings in the code, we
> should do the same in our configuration.
1) We don't make the call to AC_TRY_RUN(), so we cannot insert a parameter.
2) the warning occurs for *maintainers* when they run autoconf and
autoheader. It does *not* occur for users running ./configure
I see nothing that we can do here except to live with it (my recommendation)
or to complete reimplement our own copy of AC_C_BIGENDIAN (to use
AC_TRY_RUN_NATIVE).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/modules/dav/main config.m4
Posted by rb...@covalent.net.
> > AC_TRY_RUN allows you to provide a default for this case. Just provide
> > something intelligent, and the warning should go away. :-)
>
> The issue is that the AC_TRY_RUN is *inside* the AC_C_BIGENDIAN macro. We
> can't insert a test for the third case.
>
> AC_C_BIGENDIAN omits the param on purpose since you can't determine the
> target byte order if cross-compiling is occurring. (since AC_TRY_RUN
> actually *executes* the code, which is impossible in a cross-compile setup).
> By omitting the param on purpose, it ensures that a warning will appear for
> the ./configure author to make sure they have covered the situation.
>
> In our case, we check the "cross_compiling" variable before calling into the
> AC_C_BIGENDIAN (meaning: the person *running* configure will not have any
> problems).
I understand the issues. This is solvable however. Because we don't even
CALL the macro if we are cross compiling, just provide a relatively sane
default to TRY_RUN. This is harmless, because this code will never be
touched, but it will remove a warning that can potentially bother some
people.
IMNSHO, removing a warning that is meaningless by adding a USELESS
parameter that is never used is a win in this situation.
Imagine the scenario where you download the code, and try to compile
it. The first thing you see is a warning message. Personally, this would
scare me off a bit. We try very hard to avoid warnings in the code, we
should do the same in our configuration.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/dav/main config.m4
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Jul 01, 2000 at 08:03:59AM -0700, rbb@covalent.net wrote:
> On Sat, 1 Jul 2000, Greg Stein wrote:
> > On Sat, Jul 01, 2000 at 02:08:25PM -0000, gstein@locus.apache.org wrote:
> > >...
> > > *) do endian testing, so we can feed it into Expat to optimize that code
> > >...
> > > +dnl check for endianness
> > > +if test "$cross_compiling" = "no"; then
> > > + AC_C_BIGENDIAN
> > > +else
> > > + AC_DEFINE(AP_UNKNOWN_BYTE_ORDER,1,
> > > + [byte order is unknown due to cross-compilation])
> > > +fi
> >
> > With the introduction of AC_C_BIGENDIAN, ./buildconf will now issue warnings
> > about a missing cross-compile parameter to AC_TRY_RUN(). This warning can be
> > safely ignored.
> >
> > Basically, it is there to let you know that AC_C_BIGENDIAN isn't going to
> > work in the cross-compile case. Of course, it doesn't know that we are going
> > to check for that (see above) before calling AC_C_BIGENDIAN which calls
> > AC_TRY_RUN.
> >
> > We could clone AC_C_BIGENDIAN and write a custom version of this stuff, but
> > that feels a bit bogus (we'd lose future changes/fixes to the macro). The
> > right approach might be to print something in buildconf saying "this warning
> > is safe to ignore".
>
> AC_TRY_RUN allows you to provide a default for this case. Just provide
> something intelligent, and the warning should go away. :-)
The issue is that the AC_TRY_RUN is *inside* the AC_C_BIGENDIAN macro. We
can't insert a test for the third case.
AC_C_BIGENDIAN omits the param on purpose since you can't determine the
target byte order if cross-compiling is occurring. (since AC_TRY_RUN
actually *executes* the code, which is impossible in a cross-compile setup).
By omitting the param on purpose, it ensures that a warning will appear for
the ./configure author to make sure they have covered the situation.
In our case, we check the "cross_compiling" variable before calling into the
AC_C_BIGENDIAN (meaning: the person *running* configure will not have any
problems).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/modules/dav/main config.m4
Posted by rb...@covalent.net.
On Sat, 1 Jul 2000, Greg Stein wrote:
> On Sat, Jul 01, 2000 at 02:08:25PM -0000, gstein@locus.apache.org wrote:
> >...
> > *) do endian testing, so we can feed it into Expat to optimize that code
> >...
> > +dnl check for endianness
> > +if test "$cross_compiling" = "no"; then
> > + AC_C_BIGENDIAN
> > +else
> > + AC_DEFINE(AP_UNKNOWN_BYTE_ORDER,1,
> > + [byte order is unknown due to cross-compilation])
> > +fi
>
> With the introduction of AC_C_BIGENDIAN, ./buildconf will now issue warnings
> about a missing cross-compile parameter to AC_TRY_RUN(). This warning can be
> safely ignored.
>
> Basically, it is there to let you know that AC_C_BIGENDIAN isn't going to
> work in the cross-compile case. Of course, it doesn't know that we are going
> to check for that (see above) before calling AC_C_BIGENDIAN which calls
> AC_TRY_RUN.
>
> We could clone AC_C_BIGENDIAN and write a custom version of this stuff, but
> that feels a bit bogus (we'd lose future changes/fixes to the macro). The
> right approach might be to print something in buildconf saying "this warning
> is safe to ignore".
AC_TRY_RUN allows you to provide a default for this case. Just provide
something intelligent, and the warning should go away. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------