From owner-freebsd-ports@FreeBSD.ORG Sat Jul 31 10:07:18 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6F8116A4CE for ; Sat, 31 Jul 2004 10:07:18 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 871CB43D4C for ; Sat, 31 Jul 2004 10:07:18 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1BqqlZ-000JGi-Dd; Sat, 31 Jul 2004 12:07:04 +0200 Date: Sat, 31 Jul 2004 12:08:20 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: hartzell@kestrel.alerce.com From: Oliver Eikemeier In-Reply-To: <16651.1968.635170.809692@rosebud.alerce.com> Message-Id: <8CC36591-E2D9-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: ports@freebsd.org cc: Radim Kolar Subject: Re: configuring ports via Makefile.local X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 10:07:19 -0000 Am Samstag den, 31. Juli 2004, um 04:45, schrieb George Hartzell: > Ulrich Spoerlein writes: >> On Fri, 30.07.2004 at 18:54:44 +0200, Radim Kolar wrote: >>> Supporting Makefile.local is a good idea. It allows per-port >>> configuration without using external tools like portupgrade and >>> without making some obscure constructs in make.conf. It is easy to >>> understand and port subsystem already handles it for last 5 years and >>> there is a policy about not committing makefile.local into ports tree. >>> There is no reason for throwing makefile.local away. >> >> It only works with a R/W ports tree, and only if that ports tree is not >> shared across several machines, as is the common case. Therefore these >> options need to be host-specific. Putting them into the ports tree is a >> bad idea IMHO. You loose all changes when doing 'rm -rf /usr/ports' for >> example. > > I'd like to voice support for Makefile.local, I *like* that fact that > my configuration information is right there in the same place as the > port, no matter what machine may be mounting the ports tree. Assuming there is a new-style options tree, you could share that over nfs too, when you want to. Also you can share pkgtools.conf or similar configuration files, but you don't have to. The advantage is that you could make the options r/w while keeping the ports tree r/o. > It's always an Astonishing moment when I realize that something didn't > build the way it did the last time, just because I'm on a different > machine..... > > My biggest complaint with it is that porters don't seem to > support/test it very well, most of the bugs/patches I've been able to > contribute have involved making it work in the ports that I care > about. The problem is that: a) given the current state of the ports tree it is impossible to make it work b) nobody is obliged to test or support Makefile.local for configuring a port, since this is not a documented purpose of this file. As stated in my previous mail: It is perfectly legal (and suggested by the Porters Handbook) to simply .include in your port when you don't need the extra information provided by bsd.port.pre.mk. It is fine when you (ab-)use this mechanisms to configure your ports, like it is to play tricks with make.conf, as long as they work for you. But do not expect anyone to test or support these methods. Said that, I'm aware that configuring ports is an issue where no satisfactory solution has been found. I'm working on something that should work in most scenarios, but fear that it's hard to please everybody. Anyway, configuring ports with portupgrade or similar solution will continue to work, since these are `semi-official' tools that need to be supported. -Oliver