autoconf trouble

[Daniel Stone]

On Mon, 2005-09-12 at 00:44 +0200, Enrico Weigelt wrote:
> Let's take libXtrans as an example:
> 
> + there are some variables defined, which don't really seem to be 
>   standardized somehow. Okay, I *could* guess, that - because the 
>   package name is "libXtrans" - the library name is "Xtrans" and so
>   the variables have "Xtrans" as prefix. But that's too esoteric 
>   for serious and reliable software development.

Or you could assume that from 'lib_LTLIBRARIES = libfoo.la', that there
will be a library called 'libfoo.la'.  Either way.

> + source and header files are both listed in some variable which 
>   (by its name) seems to define header files. what do the source
>   files have to do there ?!

Apparently you don't understand how xtrans works.  Which is okay, but
don't blame xtrans's inherent badness on autotools.

> + the name and target location for the .pc file should not belong 
>   into the scope of the individual package profile, but instead be
>   completely defined by the buildsystem's configuration.
>   so these variables are junk.

So your build system is going to second-guess us, so we never get to do
things like install two .pc files.  Hmm.

> + why these unused defines, like HAVE_STICKY_DIR_BIT ?

Again, why are you projecting xtrans badness on autotools?

> + the fact whether functions like fchown exist on the target environment,
>   does not belong into a normal library like libXtrans, instead - if
>   necessary - into some separate compatibility layer, which is installed
>   *once* on the system and used by all folks. If this function really
>   cannot be supplied by it for a certain reason (ie. missing kernel 
>   side support), we at least need some dummy interface, which replies
>   an appropriate error.

What on earth?  Are you nuts?  Writing your own libc layer?

> + it seems that several features are silently enabled/disabled if 
>   autoconf thinks it has found several things. bad design.

So you say.  I submit it's good design.

> But you cannot decide which types of files to install (ie. only shared
> library, library documentation in language foo, but no includes, no 
> static library, etc.)

This doesn't even make sense to me.

> And autoconf+libtool is not suited for clean crosscompiling w/ sysroot.

Look, I've done clean crosscompiling with autotools just fine before.

Imagine that I told you that unitool sucked because it didn't support my
'solution' which involved setting $(CROSSCOMPILEROOT) and expecting
everything to work.  That's what you're doing with autotools.

So far, your arguments against autotools seem to be:
  * 'autoshit' ha ha,
  * 'it doesn't support this system I hacked up at home' (well, duh),
  * 'it tests for functions instead of having its own libc
wrapper' (?!?),
  * 'it doesn't second-guess the module maintainer and generate its own
pkg-config files, which may or may not actually be useful' (?!?).

At this point, it's just noise.  If you want to come up with an
alternate solution, just as Keith, Jim, myself, Adam, Søren, Kristian,
Jakub, Kevin, et al, all got the autotooled tree to where it is today,
please do so.  More patches are always good.  But whining on the list
doesn't help you, doesn't help me, doesn't help anyone.

Bored no.