the current autogen.sh runs a bunch of autotools without actually checking the
results … find attached a patch to add some simple sanity checks
-mike
-------------- next part --------------
A non-text attachment was scrubbed…
Name: libsdl-autotool-check.patch
Type: text/x-diff
Size: 691 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050902/a9a0ca77/attachment.patch
the current autogen.sh runs a bunch of autotools without actually checking the
results … find attached a patch to add some simple sanity checks
Thanks, your patch is in CVS.
-Sam Lantinga, Software Engineer, Blizzard EntertainmentSam Lantinga wrote:
the current autogen.sh runs a bunch of autotools without actually
checking the
results … find attached a patch to add some simple sanity checksThanks, your patch is in CVS.
This broke the Mac OS X re-configuration:
./autogen.sh
Generating build information using aclocal, automake and autoconf
This may take a while …
configure.in: installing ./install-sh' configure.in: installing./mkinstalldirs’
configure.in: installing ./missing' src/Makefile.am: installing./depcomp’
configure.in:2960: OBJCDEPMODE was already defined in condition TRUE,
which implies condition AMDEP_TRUE
OBJCDEPMODE (User, where = configure.in:2960) =
{
TRUE => @OBJCDEPMODE@
}
configure.in:2960: OBJCDEPMODE was already defined in condition TRUE,
which implies condition AMDEP_TRUE
OBJCDEPMODE (User, where = configure.in:2960) =
{
TRUE => @OBJCDEPMODE@
}
configure.in:2960: OBJCDEPMODE was already defined in condition TRUE,
which implies condition AMDEP_TRUE
OBJCDEPMODE (User, where = configure.in:2960) =
{
TRUE => @OBJCDEPMODE@
}
configure.in:2960: OBJCDEPMODE was already defined in condition TRUE,
which implies condition AMDEP_TRUE
OBJCDEPMODE (User, where = configure.in:2960) =
{
TRUE => @OBJCDEPMODE@
}
i.e. aclocal fails to run “cleanly” over here (exit 0),
but you could still continue with automake/autoconf…
But;
Perhaps now is the time to clean up the obj-c checks ?
(lots of hack/workarounds involved with that language)
–anders
Perhaps now is the time to clean up the obj-c checks ?
(lots of hack/workarounds involved with that language)
The reason the objective C stuff is left the way it is, is to handle
various broken versions of automake on various platforms. It’s the
result of several weeks of hair pulling.
sigh
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Sam Lantinga wrote:
Perhaps now is the time to clean up the obj-c checks ?
(lots of hack/workarounds involved with that language)The reason the objective C stuff is left the way it is, is to handle
various broken versions of automake on various platforms. It’s the
result of several weeks of hair pulling.
OK, perhaps now is not the time then… 
(For the Cocoa check, I just used a temp:
CFLAGS="$CFLAGS -x objective-c" workaround)
Here’s a suggestion for autogen.sh:
— autogen.sh 11 Sep 2005 04:15:44 -0000 1.4
+++ autogen.sh 11 Sep 2005 18:26:26 -0000
@@ -8,9 +8,9 @@
touch $directory/configure.in
Regenerate configuration files
-aclocal || exit 1
-automake --foreign --include-deps --add-missing --copy || exit 1
-autoconf || exit 1
+aclocal || echo “*** aclocal failed: $?” >&2
+automake --foreign --include-deps --add-missing --copy || echo “***
automake failed: $?”
+autoconf || echo “*** autoconf failed: $?” >&2
(cd test; aclocal; automake --foreign --include-deps --add-missing
–copy; autoconf)
Run configure for this platform
Less “error” more “warning”, than the original change ?
–anders
you’re hacking around the real issue imo … autotools dont abort with
non-zero exit status without good cause (most of the time ;D)
if you do (for some reason) wish to continue along that route, the final exit
status of autogen.sh should properly reflect the exit status of the
autotools … that is, it should only exit 0 if all the tools returned 0,
otherwise it too should exit with non-0
-mikeOn Sunday 11 September 2005 02:30 pm, Anders F Bj?rklund wrote:
Sam Lantinga wrote:
Perhaps now is the time to clean up the obj-c checks ?
(lots of hack/workarounds involved with that language)The reason the objective C stuff is left the way it is, is to handle
various broken versions of automake on various platforms. It’s the
result of several weeks of hair pulling.Less “error” more “warning”, than the original change ?
Mike Frysinger wrote:
you’re hacking around the real issue imo … autotools dont abort with
non-zero exit status without good cause (most of the time ;D)
Of course…
Sam just said that the current version of Objective C detection
is left that way (i.e. with non-zero exit status) in order for it
to work with all the old broken versions of autotools out there.
BTW; You should see the other hacks within configure.in then
if you do (for some reason) wish to continue along that route, the
final exit
status of autogen.sh should properly reflect the exit status of the
autotools … that is, it should only exit 0 if all the tools returned
0,
otherwise it too should exit with non-0
Perhaps, but it’s still going to fail here every single time ?
And I would still want it to run automake and autoconf, even so…
Generating build information using aclocal, automake and autoconf
This may take a while …
configure.in:2959: OBJCDEPMODE was already defined in condition TRUE,
which implies condition AMDEP_TRUE
OBJCDEPMODE (User, where = configure.in:2959) =
{
TRUE => @OBJCDEPMODE@
}
configure.in:2959: OBJCDEPMODE was already defined in condition TRUE,
which implies condition AMDEP_TRUE
OBJCDEPMODE (User, where = configure.in:2959) =
{
TRUE => @OBJCDEPMODE@
}
*** automake failed: 1
The bundled version of libtool doesn’t build a “fat” dylib, either.
So for Mac OS X 10.4u, you probably want to use autogen.sh always ?
–anders
then how about the attached patch ? that way the default behavior is still
sane but you can still force old behavior …
-mike
-------------- next part --------------
A non-text attachment was scrubbed…
Name: force-autogen.patch
Type: text/x-diff
Size: 1171 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050913/49bcaabe/attachment.patchOn Tuesday 13 September 2005 03:16 am, Anders F Bj?rklund wrote:
Mike Frysinger wrote:
if you do (for some reason) wish to continue along that route, the
final exit
status of autogen.sh should properly reflect the exit status of the
autotools … that is, it should only exit 0 if all the tools returned
0,
otherwise it too should exit with non-0Perhaps, but it’s still going to fail here every single time ?
And I would still want it to run automake and autoconf, even so…