autoconf trouble

[Enrico Weigelt]

* Shawn Starr <shawn.starr at rogers.com> wrote:

<snip>
> Exactly why is Automake not easier then bloating things with XML? 
> I like to hand edit my .am files without worrying about missing > or /'s.

Because it's not an strict declarative model.
m4 is an powerful macro-language. much too powerful for that.
And obviously autoconf does not work *reliably*.

Well, if you would use an clear and (somehow) standardized schema for
the .am files (= all packages do it exactly the same), and you would 
swear that you (virtually) never change it, I could simply code an 
separate parser for my own buildsystem (just the same way, as I wrote
an libtool-emulation frontend for unitool, my universal toolchain package)

But it doesn't really seem so.

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.

+ 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 ?!

+ 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.

+ why these unused defines, like HAVE_STICKY_DIR_BIT ?

+ 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.
  
+ it seems that several features are silently enabled/disabled if 
  autoconf thinks it has found several things. bad design.

> > That's all what's individial for libXdmcp. Evrything else is strictly
> > derived from that and implemented by an universal library build tool:
> >
> > + pathes (include, libpath, etc)
> > + compiling the sources to objects
> > + linking the objects to shared / static library
> > + generating .pc file
> > + installing all files into appropriate locations
> > + ...
> 
> We have this already and its rather easy to make a m4 macro to generate 
> a .pc file.

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.)

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

> > There are only a few points where the package is interested in platform
> > dependent stuff, ie. endianess, type sizes, etc. For that we simply
> > define some standardized symbols - this is also done by the buildsystem.
> 
> I'd say there's rather more then just a 'few'.

Well, in our example just 8 ones.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service
  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
---------------------------------------------------------------------
  Realtime Forex/Stock Exchange trading powered by postgresSQL :))
                                            http://www.fxignal.net/
---------------------------------------------------------------------