Mail Archives: geda-user/2013/02/25/11:22:49
--f46d0415580cf227d104d68eec57
Content-Type: text/plain; charset=ISO-8859-1
On 25 Feb 2013 15:37, "Peter Stuge" <peter AT stuge DOT se> wrote:
>
> 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.
True, but its best if the difference is as small as possible. gEDA
actually has a decent number of patch and one-time contributors. 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.
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.
>
> 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.
The configure scripts are the right place to document build requirements,
if at all possible. If you want release partly built stuff, its best to
make generation (and a corresponding relaxation of the requirements for
continuing the build) part of the release process.
Britton
>
> 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
--f46d0415580cf227d104d68eec57
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p><br>
On 25 Feb 2013 15:37, "Peter Stuge" <<a href=3D"mailto:peter AT s=
tuge.se">peter AT stuge DOT se</a>> wrote:<br>
><br>
> JAMES HARIG wrote:<br>
> > > There is significant difference between building from git so=
urce<br>
> > > (only done by a small number of people on a small number of =
systems)<br>
> > > and building from a snapshot or release tarball (done by man=
y more).<br>
> ><br>
> > Hi Peter, sorry to ruffle feathers. =A0What is the difference bet=
ween<br>
> > compiling from git source and the snapshot?<br>
><br>
> The difference is that git source is the raw code under development,<b=
r>
> while a snapshot or release tarball is the output of a specific<br>
> process that takes git code as input.<br>
><br>
> In many projects and cases that process doesn't do very much, whic=
h<br>
> is why many may not even realize that it is there, but it's import=
ant<br>
> to remember that there is indeed a distinct step in between the two.</=
p>
<p>True, but its best if the difference is as small as possible.=A0 gEDA ac=
tually has a decent number of patch and one-time contributors.=A0 Complex b=
uild requirements are a significant barrier to these people.=A0 They *do* m=
ake it less likely for people to get more involved with development as well=
.</p>
<p>I don't mean to be combative but it sounds sort of like you think th=
ere is no point in making the devel.=A0 build process easier.</p>
<p>><br>
> Another difference is in the numbers, as I mentioned git code only<br>
> gets built on a fairly small number of system configurations, while a<=
br>
> much larger number of people build tarballs on a much wider variety<br=
>
> of systems.<br>
><br>
> For a small target of assumedly more skilled individuals such as is<br=
>
> typically the case for builders of git code it's fine to have obsc=
ure<br>
> requirements and possibly skip build-time checks, as long as the<br>
> requirements are at least documented.</p>
<p>The configure scripts are the right place to document build requirements=
, if at all possible.=A0 If you want release partly built stuff, its best t=
o make generation (and a corresponding relaxation of the requirements for c=
ontinuing the build) part of the release process.</p>
<p>Britton</p>
<p>><br>
> For a larger target with quite likely less skilled individuals such<br=
>
> as typically the case for tarball consumers it's much more importa=
nt<br>
> to have build-time checks that will catch environment problems and<br>
> alert the builder, so that they can resolve the problem on their own.<=
br>
><br>
> How to map a missing requirement onto a given distribution package is<=
br>
> always distribution-specific, is 100% common for all software, and<br>
> can thus never be in scope for gEDA itself. Some distributions<br>
> have a search engine for finding what package provides a given file.<b=
r>
><br>
> Less skilled individuals still have to settle for binary packages<br>
> built by others for a particular static configuration.<br>
><br>
> Does that make sense? Feel free to ask for more clarification if not!<=
br>
><br>
><br>
> //Peter<br>
</p>
--f46d0415580cf227d104d68eec57--
- Raw text -