autoconf trouble

[Enrico Weigelt]

* Daniel Stone <daniel at fooishbar.org> wrote:

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

Where do we have this in the libXtrans source ? Couldn't find it.

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

Well, you're right. I just didn't imagine, that some people call
include files *.c ... but I dont ask why ...

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

Install two .pc files ? Where ? Why ?

<snip>

> > + why these unused defines, like HAVE_STICKY_DIR_BIT ?
> 
> Again, why are you projecting xtrans badness on autotools?

I've just analyzed what I've seen. I don't know what comes from autoconf
and what from elsewhere. I just see the result of all together.

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

Yes. Exactly that. 

Not the whole libc, but some smaller libs providing strictly defined
interfaces. Either an environment supports this or not. Thats how
standards like POSIX ar meant. If some platform has no or an buggy 
implementation, then the platform has to be fixed, not the application.

In fact many, many packages have their own "fix library", which of 
course is just for that package and cannot really be used by anyone
else. Thats stupid. Folks should sit together *one time* and implement
these things together, on each target platform.

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

This is nice for people who just build for themselves, on the same
machine where the package later will be running. Just type ./configure
and evrything goes alone, somehow.

But for distro builders, this soon can become very hard to maintain.
It really gets ugly, if the package silently uses some library which is 
installed on the building system, but won't be on the target.

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

You're problably no embedded-distro maintainer.

<snip>
> > And autoconf+libtool is not suited for clean crosscompiling w/ sysroot.
> 
> Look, I've done clean crosscompiling with autotools just fine before.

Yeah, I've also done this. It's just about 50% of the packages which
won't work.

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

This difference is that I'm proposing a strictly defined simplicistic 
model. An individual package's build files then are very trivial and 
just contain those information, which make it really individual 
(ie. library name, list of source files, list of include-files). 
Evryone can easily code an own implementation, if mine doesn't work 
for that.

With autoconf is isn't as easy. It starts with the complex syntax 
(ie: irregular -> requiring *at least* an stack automata).
Once we got the .am files successfully parsed, its not very trivial
to extract the right information from that, ie. there are many many
macros for doing thousands of things, which aren't relly well defined.

BTW: it shouldn't be a hard test to generate the .am files from
my model. A little shell script should do the job.

<snip>
>   * 'it doesn't support this system I hacked up at home' (well, duh),
Not really 'hacked at home'.

We're building customized distros and system images for embedded 
systems and server farms. For our customers are mainly in telco and
financial branches.

<snip>
>   * 'it tests for functions instead of having its own libc
> wrapper' (?!?),

Yes. It should instead query the systems if it supplies a certain
interface. The information comes from an database, which maybe filled 
by auto-detections the first time but can also be hand-maintained
if necessary.

The query replies whether we have some interface or not. If the target
system doesn't provide it naturally, we could supply a small library
providing an implementation.

<snip>
> More patches are always good.  

See attachement.

It's still just a hack, but should be okay for showing the concept.
I've not yet implemented system interface stuff (ie. fchown()), 
since I have to do some researches for that (ie. reading POSIX again).
This also involves defining symbol global names (global to all 
packages) and some minor rewrites in the lib.

In case of fchown() we probably have to think twice, if (the body of) 
trans_mkdir() shouldn't go somewhere else - out of libXtrans - into 
some single point of platform abstraction.

But that's another job for its own ...


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/
---------------------------------------------------------------------