- Dillo-dev - lists.mailman3.com

Q: offical bug report address?

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > AC_INIT takes an optional URL for bug reports. Should we use it, > > and what URL would be appropriate? > > Does anything happen beyond PACKAGE_BUGREPORT getting defined, and > developers getting to put it in MSG()s if they so desire? It adds a line "Report bugs to <...>" at the end of the output of "./configure --help". I agree it's not urgent but I tend to prefer following the conventions unless there is good reason not to. Regards, Jeremy Henty

Jan. 15, 2011

[patch]: clean up the build and make d_size.h static.

by corvid＠lavabit.com

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.

Jan. 14, 2011

[patch]: clean up the build and make d_size.h static.

by onepoint＠starurchin.org

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

Jan. 14, 2011

[patch]: clean up the build and make d_size.h static.

by corvid＠lavabit.com

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.

Jan. 14, 2011

[patch]: clean up the build and make d_size.h static.

by onepoint＠starurchin.org

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; > | }

Jan. 14, 2011

[patch]: clean up the build and make d_size.h static.

by corvid＠lavabit.com

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; | }

Jan. 13, 2011

Q: offical bug report address?

by corvid＠lavabit.com

Jeremy wrote: > AC_INIT takes an optional URL for bug reports. Should we use it, and > what URL would be appropriate? Does anything happen beyond PACKAGE_BUGREPORT getting defined, and developers getting to put it in MSG()s if they so desire? My opinion is that we have no particular need for it.

Jan. 13, 2011

Q: offical bug report address?

by onepoint＠starurchin.org

AC_INIT takes an optional URL for bug reports. Should we use it, and what URL would be appropriate? Regards, Jeremy Henty

Jan. 13, 2011

[patch]: clean up the build and make d_size.h static.

by onepoint＠starurchin.org

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

Jan. 13, 2011

[patch]: more spring cleaning of configure.in

by Johannes.Hofmann＠gmx.de

On Mon, Jan 10, 2011 at 09:58:43PM +0000, Jeremy Henty wrote: > Jorge Arellano Cid wrote: > > On Sat, Jan 08, 2011 at 11:31:56PM +0000, Jeremy Henty wrote: > > > corvid wrote: > > > > Jeremy wrote: > > > > > Time to retire some more obsolete autoconf macros. See [1] > > > > > for details. > > > > > > > > > > 1: Replace AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET . > > > > > > > > > > 2: Replace AC_ERROR with AC_MSG_ERROR . > > > > > > > > > > 3: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE / > > > > > AC_LANG_PROGRAM . > > > > > > > > > > This doesn't break for me, but it affects some > > > > > host-dependent parts of configure.in . It would be good > > > > > to know that this works on hosts with unusual socket / > > > > > iconv library routines. > > > > > > > > > > 4: Replace AC_TRY_LINK_FUNC with AC_LINK_IFELSE / AC_LANG_CALL > > > > > . > > > > > > > > > > This only affects target OSes *other* than linux, solaris, > > > > > osf1 and minix. Can anyone test on such a thing? > > > > > > > > > > 5: Indentation tweak for consistency. > > > > > > > > Works without giving me any problems... > > > > > > OK. Does anyone else have any concerns? Is this OK to push? > > > > +1 > > All pushed. I hope that anyone building Dillo on non-Linux systems > will report any problems as soon as possible. I can only test on > Linux so I rely on others to tell me if I break the build on other > systems. No problems here on DragonFly BSD. Regards, Johannes

Jan. 12, 2011