svn commit: r365590 - in head/cad/spice: . files

[Hiroki Sato]

John Marino <freebsd.contact at marino.st> wrote
  in <53F6724A.6000602 at marino.st>:

fr>
fr> On 8/22/2014 00:12, Bryan Drewery wrote:
fr> > On 8/21/2014 5:09 PM, Hiroki Sato wrote:
fr> >> John Marino <freebsd.contact at marino.st> wrote
fr> >>   in <53F663B2.3000800 at marino.st>:
fr> >>
fr> >> fr> On 8/21/2014 21:41, Hiroki Sato wrote:
fr> >> fr> > Author: hrs
fr> >> fr> > Date: Thu Aug 21 19:41:06 2014
fr> >> fr> > New Revision: 365590
fr> >> fr> > URL: http://svnweb.freebsd.org/changeset/ports/365590
fr> >> fr> > QAT: https://qat.redports.org/buildarchive/r365590/
fr> >>
fr> >> ...
fr> >>
fr> >> fr> I'm sorry, but using freebsd-specific <bsd.prog.mk> in a ports vendor
fr> >> fr> makefile is NOT an improvement and frankly puts the build at risk on
fr> >> fr> DragonFly.
fr> >> fr>
fr> >> fr> I wish there was a rule that ports should not use system make fragments.
fr> >> fr>  This is not a good practice.  This port had a perfectly working and
fr> >> fr> generic makefile before.
fr> >> fr>
fr> >> fr> There's a good chance this just broke spice on DragonFly as the system
fr> >> fr> make file these are different.
fr> >>
fr> >>  I can understand that vendor's Makefile should be platform-neutral,
fr> >>  but I do not think there is advantage to maintain
fr> >>  ${FILESDIR}/Makefile in a way not to use FreeBSD-specific stuff
fr> >>  because it is used only by the port.  Should we care about build on
fr> >>  DragonFly?
fr> >
fr> > No! This is FreeBSD. Ports is only officially supported on FreeBSD.
fr> >
fr> > There are plenty of other ports using bsd.prog.mk.
fr>
fr> Putting the first statement aside which frankly contradicts other
fr> statements made by other portmgr and completely belittles my
fr> contributions, this is a bad idea for FreeBSD too.  You are not
fr> containing the port to ports collection.  If the system makefile
fr> fragment changes, it affects the port. It's a dumb decision.  If you
fr> want these makefile fragments, put a tailored copy of Mk/
fr>
fr> In this PARTICULAR case, I staged the port.  I fixed that makefile.  HRS
fr> changes serve no purpose other than to potentially break my work.
fr> Obviously that is not his intention, but that is the result.
fr>
fr> Frankly he should revert this immediately.  It was working before
fr> everywhere.

 I take the maintainership because I have plans to add further changes
 to this port.  Like the other change I committed just now, they will
 be ones primarily for supporting new devices.  Probably I will change
 files/Makefile further.

 I changed files/Makefile not to use bsd.prog.mk as I understand that
 your criticism was based on the use of it.  However, still I do not
 understand what exactly you are pointing out by words "break my
 work".  I used bsd.prog.mk just because it was handy, so if my change
 was inappropriate I will consider fixing.  You first mentioned the
 breakage was on DragonFly but you did not give specifics.  If someone
 will be happy by changing something, please provide enough
 information.

 My opinion about using bsd.prog.mk is as follows.  DragonFly's
 bsd.*.mk should be based on FreeBSD's and I believe my change has
 been compatible for over 10 years.

 When a vendor-supplied Makefile is not reliable, I usually avoid to
 create a hand-rolling install target including lines of "install foo
 ${PREFIX}/bin" since maintenance is hard for me.  Although there are
 some in ports I am maintaining that have such an install target, they
 suffer from changes to the ports tree.  When staging support was
 added they became broken and needed to add ${DESTDIR} or ${STAGEDIR}
 manually, and -j# support for such kind of install targets is
 sensitive to () as tijl@ explains.  Macros in bsd.prog.mk (and
 bsd.files.mk) are safe at least with regard to them.

 I do not insist that bsd.prog.mk is free from compatibility issue
 even in FreeBSD you mentioned.  However, I personally believe risk of
 using it is smaller than (or as small as) one of hand-rolled target
 because I eventually needed to fix Makefiles before as explained
 above.  Thus, I do not either recommend or deny using bsd.prog.mk,
 while I use it in ports I maintain.  I just think the risk is small
 and I can fix it if there is a problem because I am the maintainer.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-head/attachments/20140822/f86dfbb4/attachment.sig>