On Thu, 26 Jun 2008 14:30:47 +0200 Juergen Daubert <jue@jue.li> wrote:
On Sun, Jun 22, 2008 at 11:49:47PM +1000, Lucas Hazel wrote:
I'm putting together some multilib ports in the style that has been suggested for the upcoming 64 bit test run. An issue unique to multilib, compared to pure 64 bit, is that two different sets of libraries exist on the same system. This also means that there are a different set of options required for each one to be used by pkgmk.
http://git.die.net.au/cgit/crux/ports/core/tree/pkgutils/x86_64/pkgmk.conf?h...
This is the solution Daniel came up with when he first released the original CRUX64 several years ago. While not ideal, it's a necessary evil when dealing with multilib.
The issue is that pkgutils requires the port to identify itself as a compat32 port. The method I'm using currently is to use a .arch file in the port.
Hmm, I don't understand that. The item 'port' is normaly used for the directory in which Pkgfile/.md5sum etc. are laying around. In both cases you need the port IMO, or do I miss something?
Possibly, in this implementation the .arch file is placed in the port structure along with .md5sum, .footprint, etc. The file simply contains a value for PKGMK_ARCH, which can be used by /etc/pkgmk.conf to change the environment for building that arch.
http://git.die.net.au/cgit/crux/tools/pkgutils/commit/?id=e31dab6d68b26811e9...
This differs from Daniels original implementation which was to put it into the Pkgfile using arch=compat32. However, I believe that keeping it out of the Pkgfile is a much better solution.
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(). -- Lucas Hazel <lucas@die.net.au>