Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> I'm thinking about whether we should get rid of the distprep target, ...
> Who benefits from these prebuilt files? I doubt anyone actually has
> problems obtaining useful installations of bison, flex, or perl.
I'm sure it was a bigger issue twenty years ago, but yeah, nowadays
our minimum requirements for those tools are so ancient that everybody
who cares to build from source should have usable versions available.
I think the weak spot in your argument, though, is the documentation.
There is basically nothing that is standardized or reproducible in
that toolchain, as every platform names and subdivides the relevant
packages differently, if they exist at all. I was reminded of that
just recently when I updated my main workstation to RHEL8, and had to
jump through a lot of hoops to get everything installed that's needed
to build the docs (and I still lack the tools for some of the weirder
products such as epub). I'd be willing to say "you must have bison,
flex, and perl to build" --- and maybe we could even avoid having a
long discussion about what "perl" means in this context --- but I
fear the doc tools situation would be a mess.
> The only users of this
> would appear to be those not using git and not using any packaging.
No, there's the packagers themselves who would be bearing the brunt of
rediscovering how to build the docs on their platforms. And if the
argument is that there's a benefit to them of making the build more
reproducible, I'm not sure I buy it, because of (1) timestamps in the
output files and (2) docbook's willingness to try to download missing
bits off the net. (2) is a huge and not very obvious hazard to
reproducibility.
But maybe you ought to be surveying -packagers about the question
instead of theorizing here. Would *they* see this as a net benefit?
One other point to consider is that distprep or no distprep, I'd be
quite sad if the distclean target went away. That's extremely useful
in normal development workflows to tear down everything that depends
on configure output, without giving up some of the more expensive
build products such as gram.c and preproc.c.
regards, tom lane
