Bug 192946

Summary:	put tailored copies of <bsd.prog.mk>, <bsd.lib.mk>, etc in Mk/
Product:	Ports & Packages	Reporter:	John Marino <marino>
Component:	Ports Framework	Assignee:	freebsd-ports-bugs (Nobody) <ports-bugs>
Status:	Closed Overcome By Events
Severity:	Affects Only Me	CC:	marino, portmgr
Priority:	---
Version:	Latest
Hardware:	Any
OS:	Any

Description John Marino freebsd_committer

2014-08-23 15:15:33 UTC

It came to light that at least 127 ports are intentionally using makefile fragments from the base system, e.g. <bsd.prog.mk>, <bsd.lib.mk>, etc.

As these files are out of control of ports, this is not a good idea.  Even if it's been done for 20 years, it wouldn't be the first item with done since the beginning that was ill-advised.

If people basically agree these system makefile fragments are useful for customized vendor makefiles, then I recommend that copies of the useful ones should be tailored and placed in the Port's Collection Mk/ directory, perhaps with file names like <bsd.port.prog.mk>, <bsd.port.lib.mk>, etc.

The follow-on step would be to convert those 127+ ports to use the port's version of these makefiles.

This has obvious benefits on portability as well as configuration control.

Comment 1 John Marino freebsd_committer

2014-08-23 15:16:49 UTC

Don't assign the PR to anyone, but CC portmgr@

Comment 2 John Marino freebsd_committer

2015-01-10 10:24:26 UTC

I would like to start working on this personally, soon.

The idea would be to copy over latest share/mk from FreeBSD, strip out anything world-specific or not required for ports, e.g.

usr/share/mk/bsd.lib.mk => Mk/bsd.ports.lib.mk
usr/share/mk/bsd.prog.mk => Mk/bsd.ports.prog.mk

(others?)

Those have a lot of includes, so I'd want to eliminate as many as possible or use ports versions, otherwise a bunch of other mk files would have to get sucked in.

It would be helpful to get hints/guidelines/advice before starting.  does anyone have any to offer?

The end game would be to convert ports from using <bsd.prog.mk> (etc) to <bsd.ports.prog.mk> and add a check to portlint for the former.

Comment 3 John Marino freebsd_committer

2015-01-10 10:59:37 UTC

i took a closer look -- this is not going to be easy at all.  There are many includes, each which pull in other includes -- definitely overkill.

I'm guessing most of the users of <bsd.prog.mk> and <bsd.lib.mk> are just taking shortcuts and a highly cut-down version would fit the needs of 95% but no matter how you slice it, this is a big job.

<prog> pulls in:
.include <bsd.init.mk>
.include <bsd.compiler.mk>
.include <bsd.libnames.mk>
.include <bsd.nls.mk>
.include <bsd.files.mk>
.include <bsd.incs.mk>
.include <bsd.links.mk>
.include <bsd.man.mk>
.include <bsd.dep.mk>
.include <bsd.obj.mk>
.include <bsd.sys.mk>

<lib> pulls in:
.include <bsd.init.mk>
.include <bsd.libnames.mk>
.include <bsd.symver.mk>
.include <bsd.nls.mk>
.include <bsd.files.mk>
.include <bsd.incs.mk>
.include <bsd.links.mk>
.include <bsd.man.mk>
.include <bsd.dep.mk>
.include <bsd.obj.mk>
.include <bsd.sys.mk>

Comment 4 John Marino freebsd_committer

2015-10-05 12:32:05 UTC

I'm going to withdraw this request.  I tried implementing an alternative a few months ago and it's not simple at all.