Re: [ST-devel] Re: packaging libst: autoconf and libtool

[Wesley W. T. <we...@te...>]

On Wed, Dec 26, 2001 at 01:48:00PM -0800, Gene wrote:
(reordered to make my reply coherent)
>
> I don't want to get into philosophical discussion about
> good and evil of the autoconf and libtool, but here is my
> $0.02 why they are a wrong way to go in the ST case.
>
> <snip arguements about detection vs. the sure thing>
>
> I believe the right thing to do for automated builds is to
> figure out OS and then just invoke make with the appropriate
> default arguments.  For example, if OS is Solaris 2.x, just
> call gmake solaris-optimized
>
> Minimum guesswork.  The only step which is currently missing
> is figuring out the OS.

I began to agree with this point of view when I was more than half-done the
conversion. However, to see the final result, I kept on chugging. Now,
however, I am inclined to agree with you about the truly system dependent
stuff: md.h is nice and simple

Indeed, the reason I finally came to agree with this point of view is the
MD_INIT_CONTEXT function: it really is different on each system and you have
to know what it should be. In fact, this is what the last step of my
configure script does right now at the bottom of acinclude.m4 to determine
how to context switch.

Indeed, my early worries about cross-compiling breaking are addressed by
this scheme. You know the target platform, so you don't need to guess.

On the other hand, for those things which you can reliably detect without
knowing which platform you're on, I think the effort should be made.
It's easier to maintain then having to go look at each platform.
Further, autoconf provides a means for getting the target platform.

> If the -fpic flag has to be added on Linux, it should be added in the
> appropriate Makefile section.

Here I disagree; I think automake/libtool/autoconf should be used:

1. They provide a set of options that are familiar to more users
2. They ease adoption and integration with other projects because most
developers are familiar with how to deal with these proejcts over
hand-rolled build systems
3. They are actively maintained by people who know more than us about:
a: building libraries properly on various platforms
b: what things users need to be able to control
c: what things will work with various linkers/compiler/os combinations

To summarize, I agree that the context switching mechanism should not be
guessed at. I intend to change this as soon as I fly home. I think those
things that can be guessed reliably/determined efficiently at runtime should
be.

I would draw the division as follows:
	should be looked up based on machine type (md.h):
		MD_SETJMP
		MD_LONGJMP
		MD_INIT_CONTEXT
		MD_ALWAYS_UNSERIALIZED_ACCEPT
	should be determined at runtime (at no cost):
		MD_STACK_GROWS_UP/DOWN
		MD_ACCEPT_NB_INHERITED
	should be determined without use of architecture:
		MD_UTIME
		MD_USE_SYSV/BSD_ANON_MMAP
		MD_EPOLL/KQUEUE/etc :-)

I would argue that autoconf/libtool are good things (tm) for keeping the
learning curve simple, getting correct build stuff for free, and simpler
integration.

That's my $0.02 CA. :-)

-- 
Wesley W. Terpstra <we...@te...>