From owner-svn-ports-head@FreeBSD.ORG Fri Aug 22 06:48:26 2014 Return-Path: Delivered-To: svn-ports-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A80015D; Fri, 22 Aug 2014 06:48:26 +0000 (UTC) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 010F03B39; Fri, 22 Aug 2014 06:48:25 +0000 (UTC) Received: from [192.168.0.22] (unknown [130.255.19.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 5CBAF43B99; Fri, 22 Aug 2014 01:48:06 -0500 (CDT) Message-ID: <53F6E796.7090707@marino.st> Date: Fri, 22 Aug 2014 08:47:50 +0200 From: John Marino Reply-To: marino@freebsd.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Hiroki Sato , marino@freebsd.org Subject: Re: svn commit: r365590 - in head/cad/spice: . files References: <20140822.070939.1253386656808735449.hrs@allbsd.org> <53F66EE5.7080500@FreeBSD.org> <53F6724A.6000602@marino.st> <20140822.140157.2098353200954412611.hrs@allbsd.org> In-Reply-To: <20140822.140157.2098353200954412611.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org, bdrewery@FreeBSD.org X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 06:48:26 -0000 On 8/22/2014 07:01, Hiroki Sato wrote: > John Marino 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