Bug 201208 - x11-fonts/cyr-rfx: fix build on current
Summary: x11-fonts/cyr-rfx: fix build on current
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Dmitry Marakasov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-29 20:28 UTC by Dmitry Marakasov
Modified: 2015-08-13 19:00 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (mi)


Attachments
Patch (957 bytes, patch)
2015-06-29 20:28 UTC, Dmitry Marakasov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Marakasov freebsd_committer 2015-06-29 20:28:31 UTC
Created attachment 158171 [details]
Patch

Simplify makefile, remove fmake dependency and fix build on FreeBSD current.
Comment 1 Mikhail T. 2015-06-29 20:59:48 UTC
Dmitry, could you educate me, which incompatibility between "legacy FreeBSD make" and the "new" make the existing port stumbles upon? Thank you!
Comment 3 Mikhail T. 2015-07-16 01:10:03 UTC
(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?
Comment 4 Dmitry Marakasov freebsd_committer 2015-08-13 10:23:21 UTC
(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.
Comment 5 Mikhail T. 2015-08-13 14:18:47 UTC
(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?
Comment 6 Dmitry Marakasov freebsd_committer 2015-08-13 15:24:36 UTC
(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.
Comment 7 Mikhail T. 2015-08-13 17:19:10 UTC
(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?
Comment 8 Dmitry Marakasov freebsd_committer 2015-08-13 18:43:27 UTC
(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}
Comment 9 commit-hook freebsd_committer 2015-08-13 19:00:06 UTC
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
Comment 10 Mikhail T. 2015-08-13 19:00:56 UTC
Got it, thank you!