A Cry For Sanity

[Andrew John Hughes]

2008/6/26 Andrew Haley <aph at redhat.com>:
> Andrew John Hughes wrote:
>> 2008/6/26 Andrew Haley <aph at redhat.com>:
>>> Andrew John Hughes wrote:
>>>> Is there a particular reason we keep generated files (configure,
>>>> aclocal.m4, Makefile.in) in the repository?  I ideally like to remove
>>>> them for the following reasons:
>>> It's much easier for a person who just wants to download and build
>>> not to have to regenerate the auto* scripts.  autotools are notoriously
>>> sensitive to having the exact versions installed.  If we check in the
>>> generated scripts they do not have to run auto* locally.  It's about
>>> lowering the barrier to entry: if we don't check in the generated
>>> scripts it'll be much harder for people to get started.
>>>
>>
>> It's this sensitivity that also swings it the other way from me; I've
>> had to be selective
>> on which systems I alter IcedTea to avoid drastically changing the autogenerated
>> files due to version changes in the autotools.
>
> So what?  As long as the files still work that doesn't matter.  No-one
> needs to look at the diffs between autogenerated files.
>

But they became a problem when the real diffs are obscured and we don't have
any other form of patch announcement than Mercurial commit messages.
It's hard to
track down what's being done when you have just 'New file' as a
Changelog comment
and an incomplete diff filled with useless autotools regeneration.
But that's another
topic...

>> As for people getting started, hacking on IcedTea pretty much requires
>> having the
>> autotools as most of the changes are to Makefile.am and configure.ac.
>> If you're just talking
>> about building, then that's why we have releases.
>
> That's a bad attitude problem: the source tree is for us developers,
> and mere mortals get to use the releases we've handed down from
> Mount Olympus.
>

I'm not going to anything like that extreme.  I'm merely pointing out
that someone
choosing to go to the extra length of downloading the code using a
version-control
tool and who is prepared to work with the 'bleeding-edge' would
probably expect a little
more trouble in doing so.  In the process, they would learn the skills
needed to contribute
to the project itself.  In contrast, we spend a lot of time perfecting
a release as much as possible to ensure
that there is as little trouble as possible.

This isn't about segregating users, but about making things easier for
the majority using a particular
method of source code distribution.  For a release, I believe this is
end users and distros who want to build
the code with as little trouble as possible.  With the code in the
VCS, this is the developers and prospective
developers.

>>> Now, one other thing: we should not regenerate the scripts with a
>>> simple configure and make.  If someone wants to change the
>>> generated scripts, that should be a *deliberate act*.
>>
>> Then blame whoever turned on maintainer mode, because that happens
>> with IcedTea but not GNU Classpath.
>
> Well, we should fix that straight away.
>
>>>> Anyone capable of
>>>> installing Mercurial can surely also install the autotools?
>>> That's an attitude problem.  There are far more people building
>>> than merging, and you're favouring the core developers, thus
>>> raising the barrier to entry.
>>
>> I wasn't talking about merging.  Getting a non-release copy of IcedTea
>> means you have to have downloaded the source tree to begin with.
>
> And that's already hard enough, so why not make it harder?  Sheesh.
>

I don't think obtaining the autotools is particularly hard, but I
haven't used Fedora recently.

OT, but relatively speaking, obtaining the forest extension is even harder... :)

> Andrew.
>
>
>



--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8