Bug 192946 - put tailored copies of <bsd.prog.mk>, <bsd.lib.mk>, etc in Mk/
Summary: put tailored copies of <bsd.prog.mk>, <bsd.lib.mk>, etc in Mk/
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-23 15:15 UTC by John Marino
Modified: 2015-10-05 12:32 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Marino freebsd_committer freebsd_triage 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 freebsd_triage 2014-08-23 15:16:49 UTC
Don't assign the PR to anyone, but CC portmgr@
Comment 2 John Marino freebsd_committer freebsd_triage 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 freebsd_triage 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 freebsd_triage 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.