[arch-general] Multi architecture binary pkgs
Currently, if one wants to make a pkg, lets say, for an app that only has binaries available and only for 32bit archs, then one usually makes a bin32-appname pkg for it. I don't like this and would like to have the bin32 and the non-bin32 pkgs to be just one pkg with the name of the app. But if one makes this kind of a pkg, one must use ugly if [[ "$CARCH" = .... statements are in the PKGBUILD, so I was thinking that could it be possible to implement some new variables in PKGBUILDS like depends32 and optdepends32 and then build32() {} and package32() {}? I dont know how makepkg is written, so I dont know how hard it is to implement these, but in the best case it shouldn't be more than just one or two if-statements in the code, so if arch is x86_64 use the 32 variables if they are present. -- (\_ /) copy the bunny to your profile (0.o ) to help him achieve world domination. (> <) come join the dark side. /_|_\ (we have cookies.)
On 2010/12/6 jesse jaara <jesse.jaara@gmail.com> wrote:
Currently, if one wants to make a pkg, lets say, for an app that only has binaries available and only for 32bit archs, then one usually makes a bin32-appname pkg for it. I don't like this and would like to have the bin32 and the non-bin32 pkgs to be just one pkg with the name of the app. But if one makes this kind of a pkg, one must use ugly if [[ "$CARCH" = .... statements are in the PKGBUILD, so I was thinking that could it be possible to implement some new variables in PKGBUILDS like depends32 and optdepends32 and then build32() {} and package32() {}? I dont know how makepkg is written, so I dont know how hard it is to implement these, but in the best case it shouldn't be more than just one or two if-statements in the code, so if arch is x86_64 use the 32 variables if they are present.
Hello, This seems to assume that pacman and makepkg run on systems that are either 32-bit or 64-bit. IMO, your proposal looks very "ad hoc", and would add unnecessary complications to makepkg, with no benefit when dealing with PowerPC, ARM, and other architectures. -- Rémy.
On 2010/12/6 Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
This seems to assume that pacman and makepkg run on systems that are either 32-bit or 64-bit. IMO, your proposal looks very "ad hoc", and would add unnecessary complications to makepkg, with no benefit when dealing with PowerPC, ARM, and other architectures.
However, maybe a sensible way to do that would be to allow build() function to be replaced by "build_$arch" functions in the same fashion as with split packages. -- Rémy.
On Mon, Dec 6, 2010 at 8:48 AM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
On 2010/12/6 Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
This seems to assume that pacman and makepkg run on systems that are either 32-bit or 64-bit. IMO, your proposal looks very "ad hoc", and would add unnecessary complications to makepkg, with no benefit when dealing with PowerPC, ARM, and other architectures.
However, maybe a sensible way to do that would be to allow build() function to be replaced by "build_$arch" functions in the same fashion as with split packages.
i like that idea, though i wonder if that would also entail allowing for all split functions (possibly) needing an $arch. perhaps `_$arch` could be appended to ANY function in PKGBUILD, and makepkg would use where appropriate; perhaps even build them all using chroots/etc. C Anthony
On Mon, 6 Dec 2010 15:48:52 +0100, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
On 2010/12/6 Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
This seems to assume that pacman and makepkg run on systems that are either 32-bit or 64-bit. IMO, your proposal looks very "ad hoc", and would add unnecessary complications to makepkg, with no benefit when dealing with PowerPC, ARM, and other architectures.
However, maybe a sensible way to do that would be to allow build() function to be replaced by "build_$arch" functions in the same fashion as with split packages.
In most cases, the build() function is same on every architecture, just configure,make,make install so I don't see no advantage in having build_$arch() and package_$arch() and package_$arch_splitpkgname()...this would just make the PKGBUILD huge and full of duplicate code. On the other hand, the original idea seems good to me, I'd just implement it similar way you suggested, i.e. depends_$arch=(), optdepends_$arch=() etc. You also still need to have a fallback array, like depends=() for all architectures and depends_x86_64=() specially when there will be some difference in dependencies on i686 and x86_64 etc. Dan -- -- Dan Vrátil vratil@progdansoft.com Tel: +4202 732 326 870 Jabber: progdan@jabber.cz Tento email neobsahuje žádné viry, protože odesílatel nepoužívá Windows. / This email does not contain any viruses because the sender does not use Windows.
participants (4)
-
C Anthony Risinger
-
Dan Vrátil
-
jesse jaara
-
Rémy Oudompheng