Specifying architecture in port
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. 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. Using such a method also has it's advantages in cross compiling for people who want to build ports for alternative architectures that don't have the resources to build natively, such as embedded platforms. I'm just wondering if anyone else had anything to contribute to the idea, or alternative solutions before I go too far and have another set of ports that isn't going to be incompatible with CRUX. -- Lucas Hazel <lucas@die.net.au>
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?
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.
Using such a method also has it's advantages in cross compiling for people who want to build ports for alternative architectures that don't have the resources to build natively, such as embedded platforms.
I'm just wondering if anyone else had anything to contribute to the idea, or alternative solutions before I go too far and have another set of ports that isn't going to be incompatible with CRUX.
Greetings Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
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>
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. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
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
participants (4)
-
Johannes Winkelmann -
Juergen Daubert -
Lucas Hazel -
Tilman Sauerbeck