Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 2000-02-22, Tom Lane mentioned:
>>>> Anyone for getting rid of GNU make?
>>
>> No ;-). GNU make has enough important features that there is no
>> near-equivalent non-GNU make. VPATH, for example.

> There are other makes that support this too. While I love GNU make, too,
> all the talk about allowing vanilla lex, etc. is pointless while GNU make
> is required. Users don't see lex at all, they do see make.

Huh? Assuming someone will have program X installed is not the same as
assuming they will have program Y installed. In this particular case,
a more exact way of putting it is that assuming program X is installed
is not the same as assuming that program Y's prebuilt-on-another-machine
output is usable on this platform.

> OTOH, it is very hard for me to get an overview these days what's actually
> out there in terms of other make's, other lex's, other yacc's, other
> compilers.

Not much. The real problem here is "what set of tool features do you
assume you have, and what's it costing you in portability?" GNU make
provides a very rich feature set that's widely portable, although you
do have to port the particular implementation. If you don't want to
assume GNU make but just a generic make, there's a big gap in features
before you drop down to what's actually portable to a wide class of
vendor-provided makes. VPATH, for example, does exist in *some*
vendor makes, but as a practical matter if you use it then you'd better
tell people "my program requires GNU make". It's not worth the trouble
to keep track of the exceptions.

I will be the first to admit this is all a matter of judgment calls
rather than certainties. As far as I can see, it's not worth our
trouble to try to operate with non-GNU makes; it is worth the trouble
to work with non-GNU yaccs, because we're not really using any bison-
specific features; it's looking like we should forget about non-GNU
lexes, but I'm not quite convinced yet. You're free to hold different
opinions of course. I've been around for a few years in the portable-
software game, so I tend to think I know where the minefields are, but
perhaps my hard experiences are out of date.

> The best way of going about this seems to take one of the perpetrators
> (make file, gram.y, etc.) and try to port it to some given non-GNU tool
> and take a look at the consequences.

But that only tells you about the one tool; in fact, only about the one
version of the one tool that you test. In practice, useful knowledge
in this area comes from the school of hard knocks: ship an open-source
program and see what complaints you get. I'd rather rely on experience
previously gained than learn those lessons again...

>> One thing I hope we will be able to do sometime soon is build in an
>> object directory tree separate from the source tree... can't
>> realistically do that with any non-GNU make that I've heard of.

> I'm planning to work on that for 7.1. But here's an interesting tidbit:
> Automake does support this feature but in its manual it claims that it
> does not use any GNU make specific features.

Yeah? Do they claim not to need VPATH to do it? I suppose it might
be possible, if they are willing to write sufficiently ugly and
non-hand-maintainable makefiles. Not sure that's a good tradeoff
though.

> And in fact, VPATH exists in both System V's and 4.3 BSD's make.

You're still confusing two datapoints with the wide world...

regards, tom lane