Re: Still unable to build trunk

[Jim Meyering <jim@meyering.net>]

Eli Zaretskii wrote:
>> From: Jim Meyering <jim@meyering.net>
>> Cc: eggert@cs.ucla.edu, cyd@stupidchicken.com, jan.h.d@swipnet.se,
>> emacs-devel@gnu.org
>> Date: Sun, 23 Jan 2011 18:35:17 +0100
>>
>> Requiring the installation of a few commonly-used and very portable tools
>> does not make a steep curve.  It's more of a small, one-time investment.
>
> You forget about dependencies.

Hardly.  The few programs we're talking about
(mainly just m4, automake and autoconf) have very few dependencies.

> And about upgrading from time to time.

If fencepost were upgraded more often, this would not be a problem.
If you're worried about one of these privately-installed packages
being invalidated by a (rare) upgrade, then just rerun the script
to install them from scratch again.

> With every additional prerequisite, the burden gets exponentially more
> heavy.  And it's certainly not on-time.

People participating in emacs development (even if only building
from latest cloned sources) can be expected to follow a few simple
instructions.  If they have to rerun a few commands after someone
else upgrades their development system, that does not strike me as an
unreasonable burden, and certainly not as an exponentially heavy one.

>> > Even core Emacs maintainers have trouble with these prerequisites, for
>> > any number of reasons (e.g., Autoconf installed on fencepost is too
>> > old for what Paul added to the Emacs tree, so until the GNU admins
>> > upgrade that at my request, I cannot build the current tree).
>>
>> Run the script below on fencepost, following the instructions
>> in its --help, and you should be good to go.
>
> It's not my system, so I don't want private installation of
> everything.

If you run the script and have it install only m4, automake and
autoconf, the result occupies less than 6MiB.

> My home directory there is already one of the hugest.  I
> was asked by sysadmins to go through them in cases such as this one,
> in order to avoid bloating my home directory even more.

I see that you're using over 22GiB(!) there.
Remove just one of your many emacs-*.tar.gz files
and that will free far more space than any tiny tool
installation would consume.

> Anyway, this is just an example of why adding more prerequisites is
> not something to do easily, IMO.

If we recoil from every task that at first appears nontrivial,
we will never make progress.

>> > Imagine
>> > what will happen to people with less experience and grey hair,
>> > especially if they do that on systems they don't own.
>>
>> It is most definitely a trade-off, but afaik, one that we have
>> managed well with coreutils, diffutils, gzip, grep, parted, etc.
>> On those projects, no one has reported trouble with the build process
>> for some time.
>
> I don't know if the comparison is valid.  More importantly, the fact
> that the addition is due to syncing a couple of functions with gnulib
> is troublesome -- it sounds like a tail that wags the dog.

I have endured more than my fair share of conflicts due to
version-controlled sources that are also generated by the build process.
That taught me that avoiding such trouble is well worth this type of investment.

Re "just a couple gnulib functions", Paul deliberately made the
initial introduction small.  There are many more opportunities.