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

[John Marino]

On 8/22/2014 07:01, Hiroki Sato wrote:
> John Marino <freebsd.contact at marino.st> wrote
> 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.

First, thank you for using an alternative method.  I am happy that you
have an interest in improving spice and that you are the new maintainer.

At at academic level, a port relying on a makefile fragment not
controlled by the ports collection is a bad idea.  Yes, other ports do
it and yes changes only happen per release and yes, changes rarely
happen at all.  It's still not a good idea.

The dragonfly and freebsd sys/mk have a similar function and once were
the same.  However there are differences.  As a specific example.
although ports-mgmt/pkg was developed specifically to support DragonFly,
we can't install it without patches because their internal makefile uses
system mk files and causes some files not to get installed.

I also have a "back burner" goal of putting ports on Solaris-based
machines (illuminos too) which are completely dissimilar.  Spice would
have no hope in that case.  I haven't worked on the "sun-ports" because
I've been too busy helping staging ports, something that doesn't
directly benefit dports.


>  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.


There is significant divergence after 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 would have no issue with this if a tailored copy of system mk files
were placed in /usr/ports/Mk somewhere.  It would even be a good idea.


>  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.

Since there are "only" 127 ports that visually use this (but likely
more, e.g. pkg's use is not greppable), I think it would be feasible to
put a version of these makefile fragments in /Mk and convert the ports
to use those.  I understand the benefits they can offer.

Thanks,
John