X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:content-type;
	bh=3L9nJ3B0IWj3iYWe/uJ43pOeGxFuaKp1tVSqKiJ1C+0=;
	b=poq008mGhV21Kyai3rbQDjf4vxGPE4YZThN8iWEWYbZWIzEOLfqlv8RQ0zEf5PzoBr
	053fMNKHskUdMEt+w/ilcC2Bp7kAuMs08sjBacWrhvrxTiTaCxm8Par1K8eAoA2+Gcrz
	dHERufHR++Mi3Rn3xThdKui+TkW/zPppOiNPUgKrKCmBdY9Auvw7lidfpW1WqTIP3yDP
	iWn3nSNTRTEJvmC4Vtdh51HYgczSTUZMv+pzXrA2YCJhrIhTz8QT074A7U5AxZTVVF03
	TRK4Sv53pMk2h0ZvOE/ujgrQ4BB+9EcBzJ2NdajHsh+uFyDgId+yX2IM4sSs+UhDZnD4
	c7MA==
MIME-Version:	1.0
X-Received:	by 10.42.91.7 with SMTP id n7mr16211085icm.40.1362255397320; Sat,
	02 Mar 2013 12:16:37 -0800 (PST)
In-Reply-To:	<20130225200356.6344.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>
	<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>
	<20130225200356 DOT 6344 DOT qmail AT stuge DOT se>
Date:	Sat, 2 Mar 2013 11:16:37 -0900
Message-ID:	<CAC4O8c_17O_vf7qebvgD0L3fBVf9JugNd6N8vgnB-4L-0GKDCQ@mail.gmail.com>
Subject:	Re: [geda-user] Building gEDA
From:	Britton Kerin <britton DOT kerin AT gmail DOT com>
To:	geda-user AT delorie DOT 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

On Mon, Feb 25, 2013 at 11:03 AM, Peter Stuge <peter AT stuge DOT se> wrote:
> 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?

ahh I'm sorry reading the whole thread more carefully I'd say none, autoconf
already points you in the right direction when bits are missing, if I recall
correctly.  I'd just always prefer to have autoconf tell me where to go
than have to read something.  I'm really not that lazy but when I find a
bug it goes like this:

1. Take about 10 seconds to guess packages it needs.

2. Get latest version and try build it, install dependencies if it tells
me about them at autoconf time.

3. If its still there try the same with git.

4. If its still there report it with reportbug if it has a debian
package so I can reportbug it, otherwise mailing list, otherwise dont
bother.

1-4 are often faster than dealing with BTS of random projects and you have a
chance to have the bug go away right away.  Its worth trying to have a
normal enough devel setup that 1-4 work, I think.

Britton

- Raw text -