X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <20130225133234.7146.qmail@stuge.se>
Date: Mon, 25 Feb 2013 14:32:34 +0100
From: Peter Stuge <peter AT stuge DOT se>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Building gEDA
Mail-Followup-To: geda-user AT delorie DOT com
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> <CAOkiwasj6MWJ1M-_me2PCvDk9W7nM8TQRPGNp+RYDPb4z56wAw AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOkiwasj6MWJ1M-_me2PCvDk9W7nM8TQRPGNp+RYDPb4z56wAw@mail.gmail.com>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

JAMES HARIG wrote:
> > 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).
> 
> Hi Peter, sorry to ruffle feathers.  What is the difference between
> compiling from git source and the snapshot?

The difference is that git source is the raw code under development,
while a snapshot or release tarball is the output of a specific
process that takes git code as input.

In many projects and cases that process doesn't do very much, which
is why many may not even realize that it is there, but it's important
to remember that there is indeed a distinct step in between the two.

Another difference is in the numbers, as I mentioned git code only
gets built on a fairly small number of system configurations, while a
much larger number of people build tarballs on a much wider variety
of systems.

For a small target of assumedly more skilled individuals such as is
typically the case for builders of git code it's fine to have obscure
requirements and possibly skip build-time checks, as long as the
requirements are at least documented.

For a larger target with quite likely less skilled individuals such
as typically the case for tarball consumers it's much more important
to have build-time checks that will catch environment problems and
alert the builder, so that they can resolve the problem on their own.

How to map a missing requirement onto a given distribution package is
always distribution-specific, is 100% common for all software, and
can thus never be in scope for gEDA itself. Some distributions
have a search engine for finding what package provides a given file.

Less skilled individuals still have to settle for binary packages
built by others for a particular static configuration.

Does that make sense? Feel free to ask for more clarification if not!


//Peter