[libdispatch-dev] [PATCH 2/4] check whether to add -lm for testing to compile

[Robert N. M. Watson]

On 18 Nov 2009, at 16:53, Paolo Bonzini wrote:

> On 11/18/2009 05:20 PM, Robert Watson wrote:
>> 
>> Has anyone else noticed that getting libdispatch to run on a new OS is
>> the easy bit, and that figuring out the auto*/libtool/pkg-config/etc
>> stuff is the hard bit? :-)
> 
> Uhm, I disagree.  The libtool and pkg-config bits required a bit of learning curve for some people, and next time they would have quite a headstart.  Mark has been great in incorporating pkg-config and libtool into libkqueue for example!
> 
> And the autoconf parts (including libm and the like) are _intrinsically_ part of getting libdispatch to run on a new OS.  It would be worse without autoconf, though autoconf is no global optimum (there is none), and it's definitely worth it.
> 
> Hopefully, we're just a couple of patches away from running a libkqueue-based libdispatch on Linux, and of the last 40-50 patches definitely not all of them were configury fixes.  In fact, I wouldn't underestimate _your_ work in getting libdispatch to run a non-BSD systems.  For example the conversion of the testsuite to automake was very helpful.
> 
> Just my 2 cents on "Autoconf is hard, let's go shopping" :-)

Well, my comment was meant at least partly in jest with a dash of cynicism :-). I selected autotools as the portability/build framework because it seemed to be the only realistic option, given the variables: lots of OS-specific behavior in libdispatch, and a desire for significant portability. The general hope for build systems is that you invest up-front and then pay minimal costs going forward once the framework is right, and I hope that will also be the case for libdispatch. I'm not convinced that this, as my second auto*/libtool project, was necessarily easier than my first one (OpenBSM), although I think I'm getting a bit better at it. While a lot of strength comes out of configure.ac's integration with shell scripting, it also means there's quite weak syntax checking and it can take a long time to find simple bugs that a language with stronger typing would catch easily.

On the topic of auto* feature/help requests:

(1) Is there a better way to do the MLINKS-like symlink creation in man/Makefile.am? In the BSD make framework, you use the MLINKS variable to declare a set of additional names for man pages, which at install-time result in symlinks. It would be nice if automake had a similar primitive, which created symlinks where available and copies otherwise, and in particular if the deinstall target knew how to remove them. Right now I'm using install-data-hook, probably poorly.

(2) Makefile.darwin runs all the test parts under a harness, and then collects and summarizes the results. There's a bit of non-portability in the harness still to address (as far as I'm aware, Mac OS X is the only system that has the posix_spawn flags required), but also I'd like to work from a potted example of how to hook up the test parts to the test support described in the automake documentation. Is there such a thing around to look at, or can I interest some hands in doing this?

Robert