On Thu, Feb 01, 2007 at 12:40:52PM -0800, Luigi Rizzo wrote:
> On Thu, Feb 01, 2007 at 03:25:11PM -0500, Kris Kennaway wrote:
> > On Thu, Feb 01, 2007 at 12:20:11PM -0800, Luigi Rizzo wrote:
> > > On Thu, Feb 01, 2007 at 02:44:17PM -0500, Kris Kennaway wrote:
> > > > On Thu, Feb 01, 2007 at 11:37:20AM -0800, Luigi Rizzo wrote:
> > > ...
> > > > > Now, this may well be a one-of-a-kind case calling for an ad-hoc
> > > > > solution, but if all we need is accept to use ${PREFIX}/share/mk
> > > > > for third-party .mk files, this seems a better way to handle
> > > > > the problem.
> > > >
> > > > After >10 years you are apparently the first person to want such a
> > > > feature, so this suggests the application is limited :)
> > >
> > > possibly, yes. Or maybe there were other applications solved with
> > > other hacks - e.g. (randomly browsing in /usr/share/mk), do the
> > > following really belong there:
> > >
> > > bsd.info.mk - building GNU Info hypertext system
> > > bsd.snmpmod.mk - building modules for the SNMP daemon bsnmpd
> > >
> > > They don't seem to be a part of the 'base' system unlike all
> > > the others.
> >
> > ? Those are both used by components of the base.
> >
> > > So... there is not a recursive INSTALL, maybe nobody asked for it,
> > > but certainly we have a lot of replicated constructs in the
> > > ports' makefiles, and some port maintainers with a lot of patience :)
> >
> > OK, but I don't see what this has to do with your proposal.
>
> It was a remark on "you are the first one to ask in 10 years so
> maybe the application is limited". Sometimes there is a need for
> a feature, but people find it easier to use some workaround rather
> than asking for it.OK, but showing other unrelated areas that might benefit from some centralization doesn't support your specific proposal. > The thing with bmake is that probably nothing other than the base > system uses it - most ports use gmake for portability reasons, > so maybe there is limited need to for custom 'mk' directories... > yet if we provide one, hopefully people will start considering > using it rather than workarounds (e.g. hardwiring the common > settings in the individual Makefiles). Around here we do things the other way around: show the necessity, then add support for it. Otherwise we end up with an uncontrollable proliferation of single-use features that quickly becomes unmaintainable. Kris
pgpewta9c45pN.pgp
Description: PGP signature
