Hi there, On Sun, Jun 29, 2008 at 17:37:21 +0200, Tilman Sauerbeck wrote:
Lucas Hazel [2008-06-27 09:40]:
On Thu, 26 Jun 2008 14:30:47 +0200 Juergen Daubert <jue@jue.li> wrote:
[...]
I'd not call the file .arch but find a better name that reflects more what it really does, pulling in different settings to build the port. It should be read after pkgmk.conf so it would be possible to alter other variables like MAKEFLAGS for example.
One drawback of the .xxxx file approach is that a modification of pkgmk is required, but I tend to favor that solution.
Perhaps an alternative solution would be to have a .pkgmk.conf to allow the port to make extra changes that may be required, such as extra CFLAGS, MAKEFLAGS, and so on. For example, with compat32 stuff .pkgmk.conf could contain,
. /etc/pkgmk-compat32.conf
This would remove the need for PKGMK_ARCH and the case structure in my version of pkgmk.conf.
This could also allow a number of x86_64 ports that for example, have to have -fPIC set in their CFLAGS to have the same build script as the offificial ones as in those ports as the extra CFLAGS could be set in .pkgmk.conf rather than in build().
I prefer .arch. Looks like the least intrusive approach to me. So, I'm ACKing the patches you linked to in your original mail.
Somehow, .arch seems somewhat easy to overlook, and since some code within build() might actually be arch specific I wouldn't mind having an arch= variable inside Pkgfile. However, since Pkgfiles are potentially the same for all platforms, .arch sounds like a good way to simplify merging. The only thing I was wondering was whether PKGMK_ARCHFILE should be sourced, and look something like this: # Maintainer: <someone> PKGMK_ARCH=x86_64 This way, we'd also have the arch maintainer listed. Maybe we can discuss the .arch format tommorrow at the meeting, but in either case I have no objections against merging it. Cheers, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch