Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <20130225123922.2588.qmail@stuge.se>
References: <a1278e5f88ff58af741935c7c66fe3b4 AT mail DOT theimps DOT com> <kgfk8g$ecn$1 AT ger DOT gmane DOT org> <20130225123922 DOT 2588 DOT qmail AT stuge DOT se>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F3C329AE-FFA7-43F6-94C0-FB884329C143@jump-ing.de>
Content-Transfer-Encoding: 7bit
From: Markus Hitter <mah AT jump-ing DOT de>
Subject: Re: [geda-user] Building gEDA
Date: Tue, 26 Feb 2013 21:19:13 +0100
To: geda-user AT delorie DOT com
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk


Am 25.02.2013 um 13:39 schrieb Peter Stuge:

> Kai-Martin Knaak wrote:
>> Um...
>> I always thought, the whole business of ./autogen.sh and ./ 
>> configure is to
>> to check for this kind of dependencies. Who else but those who  
>> compile
>> from git source would need to run the configure script in the  
>> first place?
>
> There is significant difference between building from git source
> (only done by a small number of people on a small number of systems)
> and building from a snapshot or release tarball (done by many more)

Do people actually build from tarballs these days? I remember well  
the days when I compiled dozens of GNU tarballs on AIX and IRIX to  
get the comfort of Linux. But today I either use a package from the  
package manager - 99% of the cases - or git directly. Even source  
code based Linuxes/BSDs have package managers these days!

> The actual thing that matters is what is *really* required to build.
>
> The build process does not in any way interact with packages, so
> packages are not relevant. Header files and symbols in libraries are.

That's entirely true. Giving a hint in which package a library/header/ 
tool can be found can't hurt, though.


Am 25.02.2013 um 21:03 schrieb Peter Stuge:

> I find it completely acceptable
> to have "significant barriers" to build from git source.

Sorry, no. Any kind of barriers should be avoided as much as possible.

> Doing any
> kind of cross-platform development, such as gEDA is, along with most
> open source, already has "significant barriers" for any developer who
> has not participated in such a project before.

Can't follow here. configure even checks wether a working compiler is  
available, it's designed to solve/check everything beyond the simple  
"./configure && make" term. How does being cross-platform enforce  
significant barriers? For my part I can't see such a dependency.

Also I don't expect READMEs to be read unless the intuitive way to  
build a package fails. Accordingly, requiring to read the README is  
sort of a barrier already :-)


my $0.02
Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/