On 21/07/2015 18:36, Buck Evan wrote:
> Apparently the 'private' keyword was added in 3.82, but many of the
> platforms I care about have older versions of make.
>
> Would you accept a patch to factor it out?
Short answer: probably not. Don't waste time on it. (But if you have
one already, send it anyway - I promise I'll look at it, without
promising I'll merge it.)
Long answer, on the side of a rant because this issue strikes a nerve
with me. If I sound exasperated, please don't take it personally - it's
not about you, it's about the amount of people who ask me for that very
same thing and it just boggles my mind. It may also be about Unix
vendors, just a little bit.
I'm definitely not interested in catering to distributions that are
incapable of providing a single update in FIVE YEARS to a piece of
software as widely used as GNU make. make-3.82 was published upstream
in July 2010. You should complain to the maintainers of your platforms,
because despite usually wanting to give people the benefit of the doubt,
I really see no other explanation than massively deployed laziness and
carelessness among Unix vendors here.
GNU make is also one of the few GNU tools that I had absolutely no
trouble compiling by hand, and that give me an impression of cleanliness
and decent engineering. It is probably easier to compile GNU make-4.1
for all your platforms that are lacking it than to work on a patch to
remove the use of the "private" keyword in my Makefiles while keeping
the same semantics.
Yes, the "private" keyword is useful, and it would not be trivial to
remove it. Even if it appears to work if you just remove it, things may
break in subtle ways in some cases; I could decide to use it package by
package, but I don't want to duplicate the work of figuring out whether
it's really necessary every time. The safe option is to always have it,
and the only price to pay is a dependency on a less than five years old
version of a widely used package.
You may have noticed I pay extreme attention to dependencies. My packages
usually require little to nothing at all; they're as standalone as is
humanly possible for Unix userspace. They depend on one another, but I
have the power to make sure those dependencies work, whereas I obviously
do not have that power with external dependencies. I don't even assume
there's a POSIX shell in /bin/sh, because even that assumption is false
on some systems! My script generators produce execline scripts: not to
be gratuitously whimsical, not because I want to shove execline down
people's throats, but because I'm certain that it will work, and if it
doesn't, then I can fix it. (And also, tbh, because it's much easier to
auto-generate than sh).
I can't fix external dependency breakage, so I avoid external
dependencies. Simple.
But make ? People wanted it. They WANTED a real ./configure and a real
Makefile. So I gave them that. I would have used POSIX make, I really
wanted to, but it so happens that it's not powerful enough to fit my
needs - at least, not without significant contortions that would have
made the build system bigger and uglier.
Make is a complex beast, so are compilers and linkers, and getting them
to do exactly what you want them to do is trickier than it should.
(Please don't mention autotools, which are an additional layer of
complexity that is even harder to get right, and of no benefit here.)
I spent most of my vacation in summer 2014 designing my new build system,
including researching make and looking for the features I needed.
make-4.0+ got them. So I settled on it.
Now my build system is good. It's more powerful, more flexible, and
more standard than my previous one, and I'm very happy with it. But I
still spent a hell of a lot of time on it, and I don't want to spend any
more - if I'm going to be coding during the summer, I would like it to be
on real code, not build systems.
So yeah, I depend on GNU make 4.0+, because it does exactly what I need.
(I didn't test 3.82; I know 4.0 works and 3.81 does not.)
Turns out that it's STILL too much of a dependency. And people are giving
me shit for a build-time requirement that should not even be debatable.
It's friggin' GNU make, lots of packages require it so it's already
installed about everywhere. And wow, my requirement is that the GNU make
package be less than two years old, as opposed to eight years old.
Apparently it's too much to ask of several Unix distributions to actually
upgrade it; well, is it my responsibility ? I'm sorry about your predicament,
I really am, because I want to make skarnet.org packages as accessible as
possible; but this is a problem that I can't fix. A fix would probably be
bugware, and I'm not going back into my build system to add bugware to work
around the fact that distributors don't see a problem in distributing an
8-year-old version of make when there's a 1-year-old one, a 2-year-old one
and a 5-year-old one.
Bottom line: I don't want to waste time on that idiotic issue that
should not even be a concern. If anything, it reinforces my opinion that
1. external dependencies are evil incarnate, 2. Unix distributors have
cream cheese for brains. (I wish. Cream cheese tastes much better than
brains, and when it comes I would enjoy the zombie apocalypse more.)
If you have a magical one-liner patch that will solve everything with
rainbows and butterflies and that I don't have to spend more than two
minutes on to be convinced it does the right thing, then please send it.
Otherwise, take your annoyance and frustration, put them in a gift-wrapped
box, and send the box to your favorite Unix vendor with my warmest regards.
(And spend 3 minutes to manually install make-4.1 on your system. It's the
best possible fix.)
Sorry about that,
--
Laurent
(I knew that using anything GNU would be trouble)
Received on Tue Jul 21 2015 - 21:39:31 UTC