Re: config-post.h + gnulib breaks separate build dirs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hrvoje Niksic wrote: > Micah Cowan <[EMAIL PROTECTED]> writes: > >> Steven Schweda has started some testing on Tru64, and uncovered some >> interesting quirks; some of them look like flaws I've introduced, >> and others are bugginess in the Tru64 environment itself. It's >> proving very helpful. :) > > Is the exchange off-list or on a list I'm not following? I'm somewhat > interested in portability myself, so I'd like to follow it. Sorry, yes, it was spawned in response to a private mail where I indicated this would be a good time to get his VMS-compatibility fixes in for 1.12. He responded by pulling down the latest dev sources and letting them break against his (somewhat VMS-like) Tru64 system :) Lessee... I've applied his fix for the fact that sysdep.h #includes and expects it to correctly #include as well (which, on Tru64, it strangely doesn't). This was easily fixed by adding that in as well. The build environment also (barely) fails to provide a C99-conformant stdbool.h, failing in an obscure case. Gnulib's provided stdbool.h then also fails, because it uses an enumeration to define true and false (#undefining and the #defining them is an "obsolescent feature" according to the standard); however, the Tru64 compilation environment apparently doesn't like their use as other-than-keywords, even when the system stdbool.h hasn't been #included. This has been reported to the Autoconf folks (for suggested changes to the "is stdbool.h provided" tests), and some of the thread is crossposted to the bug-gnulib, to resolve the fact that the provided stdbool.h breaks. The new maint.mk file, included by GNUmakefile, providing special targets for sanity-checking by the maintainer, breaks on old versions of gzip (while performing a feature test). Steven has reported this to bug-gnulib as well; apparently a fix had already been applied for coreutils, but not given back to the gnulib folks (they have diverging maint.mk's). There appears to be a build issue on systems that do not have gettext/libintl installed. I'm investigating that on an OpenBSD install right now; but was hung up on an issue with my autoconf install that was exhibiting some bugs in generating our configure script. I replaced the from-source install with the OpenBSD ports package, which solved the issue; perhaps later I'll investigate what has going on more closely, but in the meantime, I'm trying to debug Wget, not Autoconf. :) I think that sums up the problems discovered so far. - Provided stdbool.h breaks on compilers that want to treat true and false as keywords - maint.mk breaks with old gzip versions - Old broken HP systems have inttypes.h that doesn't #include stdint.h - The current handling of lack-of-gettext looks like it may be broken The first three are trivial fixes we already have (and one of which has been applied at this time); the gettext thing is probably something broken in my invocation of gettext configuration stuff in configure.ac. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGwC47M8hyUobTrERCKFcAJ9hVGgH55qktFhMD6z0rtVzxYN5XACfbPf7 XwkQnqtOf5qJ5//KEw8H2GA= =MJJp -END PGP SIGNATURE-
Re: config-post.h + gnulib breaks separate build dirs
Micah Cowan <[EMAIL PROTECTED]> writes: > Steven Schweda has started some testing on Tru64, and uncovered some > interesting quirks; some of them look like flaws I've introduced, > and others are bugginess in the Tru64 environment itself. It's > proving very helpful. :) Is the exchange off-list or on a list I'm not following? I'm somewhat interested in portability myself, so I'd like to follow it.
Re: config-post.h + gnulib breaks separate build dirs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hrvoje Niksic wrote: > Micah Cowan <[EMAIL PROTECTED]> writes: > >> Could you be more specific? AFAICT, wget.h #includes the system headers >> it needs. Considering the config-post.h stuff went at the top of the >> sysdep.h, sysdep.h is already at the top of wget.h, > > OK, it should work then. The reasoning behind my worrying is the > following: in some (rare) cases, you need to make decisions and define > preprocessor *before* including anything. In other cases, you need to > base the decisions on the contents of header files, *after* having > included everything. Case #1 used to be handled by config-post.h (and > in some cases config.h), and case #2 by sysdep.h. You have now merged > them, which I don't necessarily see as a good thing. Perhaps. I don't see any case #2s at the moment (except for where we explicitly #include the relevant header, but if we do, we'd obviously need another header. What I don't believe, though, is that it should be part of "config.h". That's a header file for a different purpose, AFA I'm concerned. It's not the idea of two system-dependency headers that bothers me, it's making config.h dependent on them, and then additionally not putting the header in the same location as config.h. >> working fine on my system (passes "make distcheck", which is _quite_ >> rigorous) > > That rigor has nothing to do with portability, though. It only > demonstrates that Wget correctly builds on *your* system. Agreed. And I expect that, between Automake and Gnulib, I've broken a number of things. Steven Schweda has started some testing on Tru64, and uncovered some interesting quirks; some of them look like flaws I've introduced, and others are bugginess in the Tru64 environment itself. It's proving very helpful. :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGMwE7M8hyUobTrERCFqbAJ4oO5dmxfcWwfnSLA1RpiNKf2huPwCeO0cf 7OtVD70SUJzS6Qol7zcel+E= =gpxu -END PGP SIGNATURE-
Re: config-post.h + gnulib breaks separate build dirs
Micah Cowan <[EMAIL PROTECTED]> writes: > Could you be more specific? AFAICT, wget.h #includes the system headers > it needs. Considering the config-post.h stuff went at the top of the > sysdep.h, sysdep.h is already at the top of wget.h, OK, it should work then. The reasoning behind my worrying is the following: in some (rare) cases, you need to make decisions and define preprocessor *before* including anything. In other cases, you need to base the decisions on the contents of header files, *after* having included everything. Case #1 used to be handled by config-post.h (and in some cases config.h), and case #2 by sysdep.h. You have now merged them, which I don't necessarily see as a good thing. > working fine on my system (passes "make distcheck", which is _quite_ > rigorous) That rigor has nothing to do with portability, though. It only demonstrates that Wget correctly builds on *your* system.
Re: config-post.h + gnulib breaks separate build dirs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hrvoje Niksic wrote: > Micah Cowan <[EMAIL PROTECTED]> writes: > >> Is there any reason we can't move the contents of config-post.h into >> sysdep.h, and have the .c files #include "wget.h" at the top, before any >> system headers? > > wget.h *needs* stuff from the system headers, such as various system > types. If you take into account that it includes sysdep.h, it needs > much more. Could you be more specific? AFAICT, wget.h #includes the system headers it needs. Considering the config-post.h stuff went at the top of the sysdep.h, sysdep.h is already at the top of wget.h, and wget.h is now at the top of each .c file, where's the issue? Note that it's currently working fine on my system (passes "make distcheck", which is _quite_ rigorous) after having made these changes, so I'd like to get specific examples of things that might break on other systems. > I don't see the problem with config-post.h, other than gnulib > brokenness. It does exactly what it was designed to do. It's not gnulib that's broken. Anything that depends on config.h (which configure will place in $BUILDDIR/src) that doesn't normally need anything from $SOURCEDIR/src would be broken. Simply adding - -I$SOURCEDIR/src for any code in other directories just because config-post.h is in the wrong place is the wrong fix; config-post.h, if it has to exist, ought to be in the same directory as config.h; I see no reason to the contrary. Which is why I mentioned having configure copy it to the build directory. However, its mere existence, as far as I can tell, is kludgy. They are system dependencies (according to its own description), and provided the code is properly organized, they belong with the other sysdeps. I see no reason why they can't all go to the same file, and measures taken to ensure that they end up at the top, before system header inclusion. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGGBH7M8hyUobTrERCO/lAJ4urjaA8DLQSyqordTIkZKiirv/CQCfREvU 5GT3Bj4tdhDSGg6Zqw11AyQ= =Pkuj -END PGP SIGNATURE-
Re: config-post.h + gnulib breaks separate build dirs
Micah Cowan <[EMAIL PROTECTED]> writes: > Is there any reason we can't move the contents of config-post.h into > sysdep.h, and have the .c files #include "wget.h" at the top, before any > system headers? wget.h *needs* stuff from the system headers, such as various system types. If you take into account that it includes sysdep.h, it needs much more. I don't see the problem with config-post.h, other than gnulib brokenness. It does exactly what it was designed to do.
Re: config-post.h + gnulib breaks separate build dirs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Micah Cowan wrote: > Is there any reason we can't move the contents of config-post.h into > sysdep.h, and have the .c files #include "wget.h" at the top, before any > system headers? It seems natural to me to have project source files > always include a "configuration" header prior to any system headers... > we already do this with config.h. If we do move wget.h to the top, we > may as well put the #include (shouldn't that be "config.h"?) > line in wget.h as well, instead of having each .c file #include it... > that way, there is only one header file that is globally common. I've gone ahead and done this; you can see the diff at http://hg.addictivecode.org/wget/mainline/rev/aa4c0498e8cc Please tell me if you see or are aware of problems with this (it Builds Fine For Me™). :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGET47M8hyUobTrERCK/TAJ0f6NLYchXftWC4ryqqKFzY+dObzQCgjmr6 wzWIu2GsG2ns8QAQxQOquOI= =aRvW -END PGP SIGNATURE-