/usr/local/share/mk ?

[Kris Kennaway]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20070201/71fc1112/attachment.pgp