[patch]: clean up the build and make d_size.h static.
These patches clean up the build system some more and then address the issue raised here[1], by using autoconf to define int32_t etc. and turning d_size.h into a static source file instead of building it. A nice simplification! Note that it depends on adding -I.$(top_srcdir) to AM_CPPFLAGS so that d_size.h can be #include-ed anywhere. 1: Finish the work begun in changeset 90603f572f75 by replacing paths that use ../ with full paths from $(top_builddir). 2: Add -I$(top_srcdir) to AM_CPPFLAGS everywhere. (This is necessary to allow the next change.) 3: Determine int32_i and friends with autoconf macros and make d_size.h a static file. Now "make distcheck" works at last! (It used to fail because d_size.h was left behind after a clean.) Comments are welcome. Regards, Jeremy Henty [1] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005135.html
Jeremy wrote:
3: Determine int32_i and friends with autoconf macros and make d_size.h a static file. Now "make distcheck" works at last! (It used to fail because d_size.h was left behind after a clean.)
I noticed that configure complained a little (although the resulting dillo works). I do seem to have the usual set in stdint.h. from config.log: configure:5280: checking for int32_t configure:5280: gcc -c -g -O2 conftest.c >&5 conftest.c: In function 'main': conftest.c:62: error: expected ')' before ';' token conftest.c:63: error: expected expression before ']' token configure:5280: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "dillo" | #define PACKAGE_TARNAME "dillo" | #define PACKAGE_VERSION "2.2" | #define PACKAGE_STRING "dillo 2.2" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define PACKAGE "dillo" | #define VERSION "2.2" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define SIZEOF_CHAR 1 | #define SIZEOF_SHORT 2 | #define SIZEOF_LONG 4 | #define SIZEOF_INT 4 | #define SIZEOF_VOID_P 4 | /* end confdefs.h. */ | #include <stdio.h> | #ifdef HAVE_SYS_TYPES_H | # include <sys/types.h> | #endif | #ifdef HAVE_SYS_STAT_H | # include <sys/stat.h> | #endif | #ifdef STDC_HEADERS | # include <stdlib.h> | # include <stddef.h> | #else | # ifdef HAVE_STDLIB_H | # include <stdlib.h> | # endif | #endif | #ifdef HAVE_STRING_H | # if !defined STDC_HEADERS && defined HAVE_MEMORY_H | # include <memory.h> | # endif | # include <string.h> | #endif | #ifdef HAVE_STRINGS_H | # include <strings.h> | #endif | #ifdef HAVE_INTTYPES_H | # include <inttypes.h> | #endif | #ifdef HAVE_STDINT_H | # include <stdint.h> | #endif | #ifdef HAVE_UNISTD_H | # include <unistd.h> | #endif | int | main () | { | static int test_array [1 - 2 * !(enum { N = 32 / 2 - 1 }; | 0 < (int32_t) (((((int32_t) 1 << N) << N) - 1) * 2 + 1))]; | test_array [0] = 0 | | ; | return 0; | }
corvid wrote:
Jeremy wrote:
3: Determine int32_i and friends with autoconf macros and make d_size.h a static file. Now "make distcheck" works at last! (It used to fail because d_size.h was left behind after a clean.)
I noticed that configure complained a little (although the resulting dillo works). I do seem to have the usual set in stdint.h.
That is very strange! Your configure has generated some completely broken C! What on earth is that "enum" doing there for a start? Or the "N"? My config.log (excerpt attached) doesn't have anything like that. Does anything suspicious appear earlier in config.log? What are your OS and autoconf versions? Regards, Jeremy Henty
from config.log:
configure:5280: checking for int32_t configure:5280: gcc -c -g -O2 conftest.c >&5 conftest.c: In function 'main': conftest.c:62: error: expected ')' before ';' token conftest.c:63: error: expected expression before ']' token configure:5280: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "dillo" | #define PACKAGE_TARNAME "dillo" | #define PACKAGE_VERSION "2.2" | #define PACKAGE_STRING "dillo 2.2" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define PACKAGE "dillo" | #define VERSION "2.2" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define SIZEOF_CHAR 1 | #define SIZEOF_SHORT 2 | #define SIZEOF_LONG 4 | #define SIZEOF_INT 4 | #define SIZEOF_VOID_P 4 | /* end confdefs.h. */ | #include <stdio.h> | #ifdef HAVE_SYS_TYPES_H | # include <sys/types.h> | #endif | #ifdef HAVE_SYS_STAT_H | # include <sys/stat.h> | #endif | #ifdef STDC_HEADERS | # include <stdlib.h> | # include <stddef.h> | #else | # ifdef HAVE_STDLIB_H | # include <stdlib.h> | # endif | #endif | #ifdef HAVE_STRING_H | # if !defined STDC_HEADERS && defined HAVE_MEMORY_H | # include <memory.h> | # endif | # include <string.h> | #endif | #ifdef HAVE_STRINGS_H | # include <strings.h> | #endif | #ifdef HAVE_INTTYPES_H | # include <inttypes.h> | #endif | #ifdef HAVE_STDINT_H | # include <stdint.h> | #endif | #ifdef HAVE_UNISTD_H | # include <unistd.h> | #endif | int | main () | { | static int test_array [1 - 2 * !(enum { N = 32 / 2 - 1 }; | 0 < (int32_t) (((((int32_t) 1 << N) << N) - 1) * 2 + 1))]; | test_array [0] = 0 | | ; | return 0; | }
Jeremy wrote:
corvid wrote:
Jeremy wrote:
3: Determine int32_i and friends with autoconf macros and make d_size.h a static file. Now "make distcheck" works at last! (It used to fail because d_size.h was left behind after a clean.)
I noticed that configure complained a little (although the resulting dillo works). I do seem to have the usual set in stdint.h.
That is very strange! Your configure has generated some completely broken C! What on earth is that "enum" doing there for a start? Or the "N"? My config.log (excerpt attached) doesn't have anything like that. Does anything suspicious appear earlier in config.log? What are your OS and autoconf versions?
Found the problem. The autoconf 2.66 release announcement http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html includes: ** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and AC_TYPE_INT64_T work again. Regression introduced in 2.65. Looking at the announcements, I'm rather surprised how many things that don't sound obscure are routinely broken. I'd think that autoconf would have so much responsibility that they would have accumulated a huge test suite.
corvid wrote:
Found the problem.
The autoconf 2.66 release announcement http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html includes:
** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and AC_TYPE_INT64_T work again. Regression introduced in 2.65.
$ autoconf --version autoconf (GNU Autoconf) 2.64 I guess it pays to be behind the times sometimes!
Looking at the announcements, I'm rather surprised how many things that don't sound obscure are routinely broken.
I think that this is a result of being insanely portable to lots of obscure systems - it leads to lots of cases that are rarely tested. I guess that these days most people have modern headers that declare int32_t etc. so the code just compiles even if AC_TYPE_INT32_T is crazy.
I'd think that autoconf would have so much responsibility that they would have accumulated a huge test suite.
Actually, both autoconf and automake (particularly the latter) have very large test suites. Try running "make check" and see! So is this a reason to hold back this patch? Regards, Jeremy Henty
Jeremy wrote:
corvid wrote:
Found the problem.
The autoconf 2.66 release announcement http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html includes:
** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and AC_TYPE_INT64_T work again. Regression introduced in 2.65.
So is this a reason to hold back this patch?
I...don't think so. My thinking went: 1. It broke harmlessly. 2. But maybe it would break seriously for someone else. 3. But if we'd made the change before 2.65 came out, would we do anything about it, or would we say "Well, that's too bad for autoconf-2.65"? No doubt the latter unless we knew of real breakage.
corvid wrote:
Jeremy wrote:
corvid wrote:
Found the problem.
The autoconf 2.66 release announcement http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html includes:
** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and AC_TYPE_INT64_T work again. Regression introduced in 2.65.
So is this a reason to hold back this patch?
I...don't think so. My thinking went: 1. It broke harmlessly. 2. But maybe it would break seriously for someone else. 3. But if we'd made the change before 2.65 came out, would we do anything about it, or would we say "Well, that's too bad for autoconf-2.65"? No doubt the latter unless we knew of real breakage.
So is it OK to push? Does anyone else have comments? Regards, Jeremy Henty
Jeremy Henty wrote:
corvid wrote:
Jeremy wrote:
corvid wrote:
Found the problem.
The autoconf 2.66 release announcement http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html includes:
** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and AC_TYPE_INT64_T work again. Regression introduced in 2.65.
So is this a reason to hold back this patch?
I...don't think so. My thinking went: 1. It broke harmlessly. 2. But maybe it would break seriously for someone else. 3. But if we'd made the change before 2.65 came out, would we do anything about it, or would we say "Well, that's too bad for autoconf-2.65"? No doubt the latter unless we knew of real breakage.
So is it OK to push? Does anyone else have comments?
*Bump* Can I push this or are there objections? Regards, Jeremy Henty
On Mon, Jan 17, 2011 at 08:58:04PM +0000, Jeremy Henty wrote:
corvid wrote:
Jeremy wrote:
corvid wrote:
Found the problem.
The autoconf 2.66 release announcement http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html includes:
** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and AC_TYPE_INT64_T work again. Regression introduced in 2.65.
So is this a reason to hold back this patch?
I...don't think so. My thinking went: 1. It broke harmlessly. 2. But maybe it would break seriously for someone else. 3. But if we'd made the change before 2.65 came out, would we do anything about it, or would we say "Well, that's too bad for autoconf-2.65"? No doubt the latter unless we knew of real breakage.
So is it OK to push? Does anyone else have comments?
I like the change and we are at autoconf-2.68 now - but I don't feel very competent in this area. Cheers, Johannes
participants (3)
-
corvid＠lavabit.com -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org