configuring ports via Makefile.local

Oliver Eikemeier eikemeier at fillmore-labs.com
Sat Jul 31 03:07:19 PDT 2004


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 <bsd.port.mk> 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



More information about the freebsd-ports mailing list