Today I exhibit my relative ignorance. After spending a lot of time with ConnochaetOS, I began to wonder: What good is the architecture field, in Arch Linux PKGBUILDs?
I mean, I’ve read this:
The arch array should contain ‘i686’ and/or ‘x86_64’ depending on which architectures it can be built on. You can also use ‘any’ for architecture independent packages.
Which might make mine an obtuse question. I really don’t use PKGBUILDs beyond the few esoteric programs I prefer, that aren’t in Arch’s Community repository.
But short of cross-compiling, and therefore needing to physically change each field each time, there’s nothing in there that isn’t defined by /etc/makepkg.conf, or by the CARCH or CFLAGS variables.
Which means, to my thinking, that it’s just a flag that stops the process, if the CARCH field doesn’t match. Isn’t that just a variable checking a variable?
Of course, this is one of those things that just shows how little I know, and so I should probably keep my mouth shut. Seems to me that, in a distro with separate packages for each architecture, making another point of declaring the architecture again is a third time and not necessarily useful.
But I don’t know everything, so feel free to teach me. But it seems like that variable, along with some other things in PKGBUILDs, could be trimmed out. Spent too much time in Crux, I guess. …
P.S.: Yes, I know about customizepkg.
Motho ke motho ka botho 
The arch field isn’t for optimization. It’s the architecture the software can run on. It’s useful because not all PKGBUILDs create packages from source. Heres’s an example:
http://aur.archlinux.org/packages/lotus-notes-sametime/lotus-notes-sametime/PKGBUILD.
This package would not run on my x86_64 Arch system.
It’s declaring, before you start building the package, where the package is known to compile without errors. Some packages you can just add the ‘x86_64’ and it will compile and run (mostly with python/java packages, I’ve noticed, because the language is designed to be architecture independent) but not all programs will compile under different architectures. Sometimes there is significant changes needed in the code itself to make it compilable on different arches. If it were easy to port to other arches, ARM would have been covered, for instance. While x86_64 is related to and similar to i686, there are a few differences.
(No worries about ignorance. I could be wrong, too. I am still a neophyte programmer.)
Hey, I’m still trying to get my ahead around i386/i686. Someone call it one, some call it the other, yet they both refer to the same thing?
Not quite.
i386 refers to anything compatible with the Intel 80386, a processor two generations older than the original Pentium. i386 indicates that none of the optimized instructions (MMX, SSE, et cetera) available in later CPUs are used or required.
Software compiled for i386 will run on any x86-type CPU, albeit more slowly — especially for multimedia apps.
i686 refers to anything compatible with the Pentium 2 or newer. It indicates that MMX and SSE instructions are used/required — thus better performance in applications that take advantage of them, but REQUIRES a Pentium 2 or compatible, or newer.
At least, that’s my understanding. 😛
Silly boy, i686 is the Pentium Pro’s version. It doesn’t need MMX, and SSE was introduced with the PIII.
I see. I’ve been looking at it from the perspective of a braking flag or a continuous error to be avoided, where it’s more intended for weeding out software that won’t run on one or the other architecture.
Thanks everybody. 😉
Pingback: My uglified ConnochaetOS beta 2 desktop « Motho ke motho ka botho