Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)

[Jamie Lokier <jamie@shareable.org>]

Enrico Weigelt wrote:
> > Reality is that Kconfig front end to autotools does work - as you've
> > proved.  It's a good idea. :-)
> 
> Now, we just need an autoconf-alike frontend for Kconfig ;-)

I agree and would support:

    ./configure --menu
         Invokes a configuration menu / wizard for user-selectable options.
         Only works if you have the "autoconf-menu" tools already installed.

    ./configure --ask
         Invokes command line configuration questions / wizard for
         user-selectable options.

    ./configure --ask --from-config=OLDCONFIG
         Uses existing settings from a previous configuration.

    ./configure
         Without --menu or --ask, invokes traditional Autoconf
         automatic detection of capabilities.

> > You said about too many user-selectable options.  Many large packages
> > _check_ for many installed libraries.  Get them wrong, and you have
> > the same problems of untested combinations.
> 
> It even gets worse when they silently enable certain features on
> presence/absence of some lib. That's btw one of the reasons why
> sysroot is an primary constraint for me, even when building for the
> platform+arch.

That's a basic design feature of Autoconf.  And it really is very good
most of the time - much better than config scripts which ask a lot of
questions (Perl).

> > Have you felt uncomfortable shipping a package that does use Autoconf,
> > Automake and Libtool, knowing that the scripts generated by those
> > tools are huge compared with the entire source of your package?
> 
> Yeah, that's one of those things in autotools I never understood:
> why isn't there just one function for each type of check/action, 
> which is just called with the right params ?

It's because it's written in very portable Bourne shell, which does
not support shell functions.

(This is why I toy with the idea of writing a very portable C program,
similar to a simplified shell, specially designed for Autoconf, with
functions...)

It could simulate functions portably by creating lots of little
scripts at the start, and then calling them later on.  That would
shrink ./configure a lot.  But it's a big change; somebody's got to do
it, test it, look after it, and so on.

Libtool similarly does not have to be huge, but it would be a lot of
work to shrink it without breaking anything.  It's hard enough to
change it at all without breaking anything on some system, somewhere.

-- Jamie