Jos Backus wrote:
> On Sat, Jun 01, 2002 at 11:45:15AM -0600, Ian wrote:
> > Actually, I think it's a great idea. It should make life much easier for
> > people creating and maintaining ports.
>
> My thoughts exactly.
Any port that switches to BSD make because the Makefile uses
this *one* GNU make specific feature, and it becomes implemented
in BSD make, is just asking for it.
Any existing port maintainer doing a proper risk analysis will
not fall into this trap.
A maintainer of a new port *might* have marginal benefit (which
I would argue would be transient, at best) IFF this is the only
GNU make specific feature that the Makefile uses (this is a
small subset of potential work).
You are assuming that someone who uses one GNU make specific
feature now, will not use more GNU make specific features in
future versions of their code, going forward.
I would argue that this is a low probability bet:
o They are already using GNU make as their baseline for
selection of which features they are going to exploit
o The have implicitly demonstrated their lack of care
for portability in their use of the feature in the
first place
o Programmers naturally gravitate towards use of more
and more esoteric features of tools as they learn to
use their tools
o We have to assume that GNU make is at least moderately
well designed for this discussion -- if it isn't, it
would be a bad idea to imitate it -- and so the other
features it implements but BSD make does not also have
their purpose within that design. This will promote
their use by programmers
The most likely outcome is that the maintainer for the original
GNU make specific code will include more GNU make specific features
in the Makefiles, over time, going forward.
When this happens, the port maintainer will be faced with one of
two options:
A) Switch the port back to GNU make, wasting the work they
did to switch it to BSD make in the first place
B) Modify the BSD make to implement the newly used GNU make
feature, so that the port does not have to be switched
Both of these options are effort intensive. Both of them entail
work that would not be necessary, had the porter simply made the
port depend on the GNU make port ("gmake"), like all other similar
ports currently do.
If you want to make the argument that implementation of GNU
features in all tools and/or a switch to GNU tools would result
in more software being available for FreeBSD: make that argument,
don't try to approach it tangentially and sneak the idea in under
everyone's radar.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
