Re: A Closer Look at GNU AutoTools
Shawn H Corey wrote: I have just added an article to my blog on my programming language about the GNU AutoTools. Please feel free to comment. http://kori-programming-language.blogspot.ca/2014/09/a-closer-look-at-gnu-autotools.html i wanted to comment on this that you should take a look at https://github.com/GregorR/autoconf-lean , because using autoscan results in a boatload of bloat and nastyness. however you can only comment there using a google plus account, which i cannot create due to lack of a mobile phone. (and even if i had one, i wouldn't want to register there anyway because then google could link almost any activity happening in my webbrowser to my ID). so maybe you should revisit the decision where you host your blog. --JS ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
cross-compilation and proprietary pkg-config replacements (pcre-config, pcap-config, etc)
Hello! I'm currently in the process of adding cross-compilation support to a linux distribution, but I'm running into a lot of nasty issues. The #1 offender are proprietary pkg-config replacements, and there are many. They break cross-compilation by returning non-sysrooted include and library directories from the host, like -I/usr/include or -L/lib. I'm glad to say that autoconf itself is one of the few components that properly handle cross-compilation. It seems it's en vogue for libs to ship their own broken replacement rather than supplying a portable pkgconfig file... the list is big, but these here are the most often used ones: pcap-config, pcre-config, freetype-config, apr-1-config, glib-config, gtk-config, ncursesw5-config, libmikmod-config, etc. (in a proper setup those are not even needed, unless they installed headers into a custom subdir in the standard include path. otherwise just returning -lmylib is the only thing that's needed.) since it's unlikely to get any of those fixed in the next decade (or even convinced to ship .pc files instead of their NIH'd pkg-config replacement), my idea was to add support for them into autoconf itself: Offer a m4 macro for each of them (or a generic external config macro), which then calls these config tools and prefixes the returned include and library paths with the sysroot path (passed to configure via --with-sysroot=). so packagers depending on these libraries would use the provided macros rather than hardcoding their own test. Does this sound viable and acceptable for inclusion ? Or is there another workaround that i missed ? Regards, --JS ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: configure speedup proposal: add --assume-c99 and --assume-posix2008 flags
Ralf Corsepius wrote: On 03/23/2014 01:24 AM, John Spencer wrote: and for posix - sizeof int == 4 - have select() - etc These assumptions are unsafe, esp. on non-mainstream architectures/OSes, which only partially implement c99. E.g. it's not that uncommon to find toolchains for embedded platforms which implement most of C99, but with sizeof int != 4 or without select(). well, noone forces you to use --assume-compliant-c99. as outlined in my previous responses, the usage is *optional* and *not default* and you would only use it on known non-broken platforms (i.e. those that implement C99 to the letter of the standard, for example linux + musl libc). ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Information on mailing list archives page is wrong
http://lists.gnu.org/archive/html/autoconf/ says that the archive is updated every 30 minutes - this seems to be untrue. it seems to take at least 4 hrs - so please excuse my double-post (and maybe consider updating the information on that page). Thanks, --JS ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: configure speedup proposal: add --assume-c99 and --assume-posix2008 flags
Russ Allbery wrote: John Spencer maillist-autoc...@barfooze.de writes: having an option like --assume-c99 could provide a shortcut so all checks like - have stdint.h - have snprintf() - etc These are un-alike, just to mention. A surprising number of platforms have an snprintf function that's broken. To test it properly, you need something akin to the gnulib snprintf check, and it's broken in enough places that you may not want to assume the result. Some of the problems with snprintf are also quite serious. For example, Solaris 9 (which I believe is otherwise C99-conforming) would return -1 when given NULL, 0 as the first arguments to snprintf, which makes it impossible to use snprintf safely in many programs. See: https://www.gnu.org/software/gnulib/manual/html_node/snprintf.html for more information about the portability mess. point taken, although all the platforms described there are not exactly what i would call modern, my leaning would be more towards calling them broken, obsolete or simply undead. thinking_loud i even ask myself sometimes if it is still worth plastering software and configure scripts with checks and ifdefs for these broken platforms that probably cant even build the dependencies of modern software (these ifdefs are almost always completely unmaintained due to lack of testing and very likely to fail), and even if they still compile *and* work there, are probably not even used. because the handful of people using these platforms stick to their current versions anyway... speaking of it, it may be a good test to revive one of these zombie OS's trying to do a full build of the 500 most popular non-linux-specific packages in debian to proof that probably less than 10% will compile despite extensive platform-specific hacks and workarounds. carrying around all this legacy baggage is kinda like porting a 16bit DOS program to win 3.11, then to win95, 98, xp, 7, 8 and still keeping all the old 16bit code in #ifdefs without testing it ever. btw, to this day i've yet to see a library or program, that for example checks for unistd.h, and then uses HAVE_UNISTD_H consequently in all TUs, including optional usage of any of its exported functions. this probably worked once, when the initial autoconf support was written and tested, but the next developer that came along just used unistd.h without any conditionals... /thinking_loud note that my suggestion is not to default to this shortcut, it's meant to be used by users that know that their platform is fully compliant, so it wouldnt affect users of these systems. but maybe to make it more clear, the option should be called --assume-c99-compliance instead. --JS ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: configure speedup proposal: add --assume-c99 and --assume-posix2008 flags
Bob Friesenhahn wrote: On Sun, 23 Mar 2014, John Spencer wrote: there are many configure scripts out there that still check for things that are standard since at least 10 years, and doing this extensively and over and over (people building software themselves usually build more than one package) consumes a lot of time (especially due to the non-parallel nature of configure scripts). often configure scripts take longer to finish than compiling the source code itself on decent machines with multiple cpu cores. Agreed. having an option like --assume-c99 could provide a shortcut so all checks I don't like any approach which hard-codes assumptions in Autoconf. Hard-coded assumptions can easily be wrong and configure scripts could be used ten years later without being re-generated with the latest rules. The Autoconf configuration cache mechanism (e.g. --config-cache) is very effective. In my test here, using --config-cache reduced repeated configure run time from 20 seconds to 5 seconds. By transcribing selected lines from config.cache to config.site, these cached values can be made the default for a system. Modern autoconf searches for both $prefix/share/config.site and $prefix/etc/config.site and will use whichever ones are found. yes, i currently use an approach that copies a custom config.cache into the builddir. however this implicates a maintenance burden, and i heard some voices criticizing that approach as to unreliable. using a config.site in place of my manual approach is interesting and may make it look a little bit more legitimate, however it's essentially the same. what i'm trying to achieve is that there's some kind of official upstream stategy (like currently the config.site usage) that could be used/consumed easily (i.e. without having to manually maintain the cachefile). E.g. egrep '^ac_cv_func_select' config.cache /usr/local/share/config.cache and in /usr/local/share/config.site . /usr/local/share/config.cache In fact, one could take a boilerplate configure.ac, use it to create a bare configure, and then use most of its config.cache to form config.site. this is a good idea. maybe autoconf could ship a config.site generator script which tests the libc capabilities in regard to c99 and posix 2008, and generates the cache for usage in a systemwide install? testing anything else like for example whether ncurses.h is installed is imo bogus, as the user could easily remove ncurses-dev from his box after having run through the .site-generator script. otoh it's unlikely that his libc implementation removes functionality that it already had. despite that, the script should definitely display a warning that it should be rerun whenever the libc was updated. having this script available as part of autoconf would make it easily accessible to distribution maintainers, so everyone could benefit. With this approach, Autoconf can be optimized for a system with known behavior without placing brittle assumptions within Autoconf itself. A separate script could be used to create a reusable subset of config.cache based on a specification. BTFW that some software might not configure correctly given the presence of a config.site file. In my experience, a config.site file can cause harm when configuring GCC. i didnt experience this sort of problem with gcc, but i had some cases where the information in my handtuned config.cache was outdated and caused build failures. --JS ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
configure speedup proposal: add --assume-c99 and --assume-posix2008 flags
there are many configure scripts out there that still check for things that are standard since at least 10 years, and doing this extensively and over and over (people building software themselves usually build more than one package) consumes a lot of time (especially due to the non-parallel nature of configure scripts). often configure scripts take longer to finish than compiling the source code itself on decent machines with multiple cpu cores. having an option like --assume-c99 could provide a shortcut so all checks like - have stdint.h - have snprintf() - etc and for posix - sizeof int == 4 - have select() - etc could be skipped and assumed to be always true. only functions which are known to be non-conforming on some platforms (like the broken strerror_r() semantics of GLIBC which conflict with POSIX when certain CPPFLAGS are used), and special platform specific things like linux extensions needed to be checked separately using this mechanism. to me, this sounds like a simple way to make configure runs at least 50% faster on most modern platforms, while not impacting legacy systems negatively at all. having configure run much faster could also lead to a better public perception of autoconf in general. as for how to implement, maybe these flags could just set the appropriate autoconf cache variables to true. regards, --JS ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
