Created attachment 158171 [details] Patch Simplify makefile, remove fmake dependency and fix build on FreeBSD current.
Dmitry, could you educate me, which incompatibility between "legacy FreeBSD make" and the "new" make the existing port stumbles upon? Thank you!
http://beefy4.nyi.freebsd.org/data/head-amd64-default/p391608_s285299/logs/cyr-rfx-koi8-o-1.1_4.log
(In reply to Dmitry Marakasov from comment #2) Yes, the build log ends with: > "/usr/share/mk/sys.mk", line 36: Unknown directive > "/usr/share/mk/sys.mk", line 364: Unknown directive > Unknown modifier 'U' which to me suggests a problem in src/ not in ports/ The port itself does not use U-modifier -- src-developers need to fix sys.mk... At least, that's how I read the error. Do you disagree?
(In reply to Mikhail T. from comment #3) > (In reply to Dmitry Marakasov from comment #2) > Yes, the build log ends with: > > > "/usr/share/mk/sys.mk", line 36: Unknown directive > > "/usr/share/mk/sys.mk", line 364: Unknown directive > > Unknown modifier 'U' > > which to me suggests a problem in src/ not in ports/ > > The port itself does not use U-modifier -- src-developers need to fix > sys.mk... At least, that's how I read the error. Do you disagree? I do. system .mk files are designed for system make, while this port uses legacy fmake AND system .mk files.
(In reply to Dmitry Marakasov from comment #4) Dmitry, the round-trip latency observed in this conversation well exceeds that of interplanetary communications... > system .mk files are designed for system make, this port uses legacy fmake This was an (unauthorized) change by bapt@, which I'll be happy to see undone, but I doubt, it made a difference. Does the system make in -current, once again, recognize the :U modifier? The patch you propose removes the fmake-reference, which I understand, but it also changes my use of VPATH, which I do not. Is it important, or just something cosmetic?
(In reply to Mikhail T. from comment #5) > > system .mk files are designed for system make, this port uses legacy fmake > > This was an (unauthorized) change by bapt@, which I'll be happy to see > undone, but I doubt, it made a difference. Maintainer approval is not required for changes which fix build. fmake was required for your Makefile which is not compatible with our system make on 10.x and above. > Does the system make in -current, once again, recognize the :U modifier? > > The patch you propose removes the fmake-reference, which I understand, but > it also changes my use of VPATH, which I do not. Is it important, or just > something cosmetic? It is important. VPATH prohibits it from building fonts.alias: VPATH Colon-separated (“:”) lists of directories that make will search for files. The variable is supported for compati‐ bility with old make programs only, use ‘.PATH’ instead. With it, make just finds fonts.alias in either misc/ or 75dpi/ and considers fonts.alias target as up to date, not producing merged file.
(In reply to Dmitry Marakasov from comment #6) > Maintainer approval is not required for changes which fix build. Yes, an bapt is also a portmgr-member. I'm not complaining about rule-violations, just shifting the blame. > fmake was required for your Makefile which is not compatible with our system make on 10.x and above. Obviously, I'd rather the Makefile was fixed... > It is important. VPATH prohibits it from building fonts.alias: So, you are saying, the handling of VPATH by the make(1) has also changed subtly between 10.x and 11.x? I still don't understand, why the :U modifier is used by system mk/ files in 11.x -- did the make(1) in -current regain the handling of :U (and :L), that was abandoned in 10.x?
(In reply to Mikhail T. from comment #7) > > fmake was required for your Makefile which is not compatible with our system make on 10.x and above. > > Obviously, I'd rather the Makefile was fixed... Me too. > > It is important. VPATH prohibits it from building fonts.alias: > > So, you are saying, the handling of VPATH by the make(1) has also changed > subtly between 10.x and 11.x? It has changed earlier, probably in 10.x. VPATH handling is the same in 10.x and 11.x. > I still don't understand, why the :U modifier is used by system mk/ files in > 11.x -- did the make(1) in -current regain the handling of :U (and :L), that > was abandoned in 10.x? :U in bmake means another thing: :Unewval If the variable is undefined newval is the value. If the variable is defined, the existing value is returned. This is another ODE make feature. It is handy for setting per-target CFLAGS for instance: ${_${.TARGET:T}_CFLAGS:U${DEF_CFLAGS}} If a value is only required if the variable is undefined, use: ${VAR:D:Unewval}
A commit references this bug: Author: mi Date: Thu Aug 13 19:00:00 UTC 2015 New revision: 394184 URL: https://svnweb.freebsd.org/changeset/ports/394184 Log: Stop using the "legacy" fmake, adjust the Makefile to work with the newer bmake. PR: 201208 Submitted by: amdmi3 Changes: head/x11-fonts/cyr-rfx/Makefile head/x11-fonts/cyr-rfx/files/Makefile.bdf2pcf
Got it, thank you!