FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Embedded

 
 
LinkBack Thread Tools
 
Old 01-03-2011, 02:00 PM
Peter Stuge
 
Default configu error: C++ compiler cannot create executables

Enrico Weigelt wrote:
> > and I'm asking myself, why its not done every install, or why we
> > get ./configure generated in the tar.gz.
>
> These arguments I've heared over the years:
>
> a) save time and cpu cycles for end users
> b) get around autotools version conflicts
> c) we always did so, so why change ?

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.


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


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


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

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.


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


//Peter
 

Thread Tools




All times are GMT. The time now is 05:36 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org