Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Enrico Weigelt]

* Peter Stuge <peter@×××××.se> schrieb:

> I think you're missing the point then. The point is obviously to
> allow source packages to compile on a very wide variety of platforms.
> Specifically, the auto* packages should not be needed on the build
> system. This is why configure is included in releases, and tries to
> run on as many different shells as possible.

Yes, but that whole idea introduces a hell more trouble than it's
ever worth it. Starting with the fact that they have to use a
very ancient shell language or even ugly hacks to work around
incompatibilities between ancient shells.

If we'd at least expect quite recent a shell that is capable of
handling functions, the whole machinery could be written entirely
in shellscripts - no macro-based generation at all. When appropriate,
there could be different, platform specific, version of these functions,
which are just included by the detected host and target type. A simple
configure script the probably would look like this:


    #!/bin/sh

    PACKAGE="mypackage"
    VERSION="1.2.3"
    AUTHOR="foo@×××.de"

    . cf/autoconfig.sh

    autoconfig_init

    declare_feature	"compression"	"enable compression support using zlib"
    declare_feature "png"		"png image loading support"

    autoconfig_begin

    if `feature_enabled compression` ; then
	require_header	zlib.h
    fi

    if `feature_enabled png` ; then
	require_package	PNG	"png >= 1.4.0"
    fi

    check_header	malloc.h

    generate_files	\
	Makefile	\
	src/Makefile	\
	doc/Makefile	\

    autoconfig_finish


Everything else could be easily hidden behind the shell functions.

> > The best solution, IMHO, would be replacing all these dubious
> > macros by a bunch of carefully written shell functions.
>
> Of course you already know that in fact the macros *are* shell
> functions. Look in a generated configure. They may be unrolled,
> but still.

No, they aren't. They are just macros which are expanded to a big-fat
unreable shellscript w/o any functions.

> > There would be no generation phase at all.
>
> Generation would be traded for a build-time requirement to have the
> library of shell functions installed on the system. Such a regression
> is not an option.

The shell functions could simply be included in the source tree
(eg. in some sane subdir). And the main script could even have some
switching mechanism, so an already installed version can be used
when requested.


    AUTOCONFIG_LIBRARY=/usr/share/autoconfig-1.2 ./configure <....>


> > I've started some hacking on that for zlib, a while ago. Maybe
> > somebody might like to join me ...
>
> It would be interesting to see what you come up with there. IIRC zlib
> is not using full-on autotools though?

It's not using autotools at all - everything hand-written.

> Rewriting autoconf to use sh instead of m4 is an interesting idea. I
> think it would make sense to phase out m4. But I also don't think it
> is a strong requirement.

For me it often becomes requirement as during the last decade, it's
macros have turned out to be so broken and hard to debug.
 
> > I'd rather propose (on per-package basis) directly maintain the sources
> > (including dist-specific changes) in an own repository, so the whole
> > download+unpack+patch phase is replaced by just a checkout, and things
> > like rebasing dist-specific changes can be done directly via vcs.
>
> Except that it creates a proper fork of every package, which is
> pretty stupid IMO.

No, it's not a full fork, but just a downstream branch. Essentially the
same as done w/ text-based patches, just now stored directly in an 
sophisticated vcs which supports the common operations like rebase.

> Yes this happens in practise with patches too, but
> in my view patches are really only temporary fixes until upstream has
> solved the problem better.

Same with an downstream-branch. Once upstream has taken a change, it
will automatically disappear from the downstream own changeset line
(which sits ontop the upstream) on next rebase. That's one of the
things rebase is good for.

> The purpose of a source-based distribution is to use the upstream
> sources. Some upstreams have significant QA which it would be silly
> to not take full advantage of, by using their released archive.

In the generic case, you don't use the upstream sources, but upstream
plus certain patches (or even worse: esoteric manipulations v/ sed, etc).
Only a subset (no matter which percentage it actually makes up) of the
package releases can be _directly_ pulled from upstream. The more
generic case is the superset of releases where a variable number
of changes (which *might* be zero) has to be added to the release.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  [phone]  email: weigelt@×××××.de
 mobile: [phone]  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------