X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <20130225200356.6344.qmail@stuge.se>
Date: Mon, 25 Feb 2013 21:03:56 +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> <20130225133234 DOT 7146 DOT qmail AT stuge DOT se> <CAC4O8c-BRxMJj71bP2f5UjUP-WNra-=rUJ6woZyzdtXDoOKHWg AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAC4O8c-BRxMJj71bP2f5UjUP-WNra-=rUJ6woZyzdtXDoOKHWg@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

Britton Kerin wrote:
> > 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.
> 
> True, but its best if the difference is as small as possible.

Yes of course, but there must be no increased cost for tarball consumers.


> Complex build requirements are a significant barrier to these people.
> They *do* make it less likely for people to get more involved with
> development as well.

gEDA isn't a super simple project so I find it completely acceptable
to have "significant barriers" to build from git source. 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. It doesn't make sense
to dumb things down, instead I think it makes sense to do smart and
convenient things, even if they require one-time complexity for those
who want to deal with git code. I understand that many developers
find that balance unacceptable. They may want to stick to simpler
projects targeting fewer platforms.


> I don't mean to be combative but it sounds sort of like you think
> there is no point in making the devel.  build process easier.

I'm all for making development easier, but never at the cost of
having something imprecise, and if there is a one-time cost that
before development can commence I find that perfectly fine too.

I don't know if configure can currently reliably determine if it is
run as part of a git source build or a tarball source build.


> > 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.
> 
> The configure scripts are the right place to document build requirements,
> if at all possible.

Sure, but remember that configure is generated as part of the
snapshot/release process, and it needs to be able to tell if it is
used with a git build or a tarball build. I believe something like
that would be quite exceptional (not in the good way) for a configure
script. I haven't seen it in any project, at least.


> If you want release partly built stuff

That's the case not only for the files that this thread is about,
but also for configure itself.


> (and a corresponding relaxation of the requirements for continuing
> the build) part of the release process.

So what changes should be done in the configure source?


//Peter