Originally Posted by T3slider
[..]demands that you learn a whole other process, which although efficient to maintain from Stuart Winter's point of view (and possibly the only way to maintain such a project as a single person), becomes a frustration from not being able to use Slackware in the same way just because of an architecture difference. Obviously ARM's kernel requirements make a catch-all distribution impossible but a unified Slackware ARM port would be highly desirable, at least to me. Note that I do not intend to diminish the ARMedslack project, which is and has been fantastic.
Slackware ARM/ARMedslack started as an unofficial port, so I had to out of necessity have a separate tree, that was easy to maintain (which is still is, at least in terms of keeping up with x86 development). There's now over ten years of development history there which even now is still quite useful for me when developing.
For those who are saying how it'd be easier for *them* - I'm the only one who develops Slackware ARM, so it has to be the easiest for me to maintain. Since Slackware is not a 'from source' distribution such as is Gentoo, there's no need for everyone to understand how to use my build system up front. However, I have made ample effort to document it - and the Slackware ARM source tree and build scripts are sometimes more verbosely documented than x86 (mostly for my own benefit in the first instance, but for those of you want to read and learn, it's there in the open). On the other hand, did anybody really try using the x86 scripts? From some of the posts it doesn't sound like it. If you did, you might find that many of them are perfectly fine on Slackware ARM as is, with no modification -- since a while ago, Pat took the auto arch detection & CFLAG settings from my scripts and added them into the x86 tree. The CFLAGS are for armv4t in there at the moment, but it's no big deal to change it if you so wished.
None of us apart from Pat are able to make changes to the source tree, so it's *far* easier and less time consuming to have a separate tree in order to fix bugs and apply patches quickly. Obviously if I fix something for ARM that applies also to x86 then I give Pat a heads up.
As anybody who's programmed or scripted -- you develop your own style. As some of you who've perused Slackware ARM's source tree will see, the build scripts are somewhat different (although the main sections are the same). Part of my enjoyment (albeit only a small bit) is coming up against something in the x86 scripts that I'll optimise or just re-style to my own taste, but still achieve the same resulting package.
Finally, the current SlackBuild scripts need further work more than just setting some CFLAGS. There are some obvious ones that spring to mind such as using gzip to compress packages rather than LZMA; since many ARM devices don't have much RAM so I foresee trouble with LZMA on ARM. There are a few other points to consider (which I've discussed briefly with Eric & Pat but don't recall them off the top of my head), but until such a time that my interest wavers in maintaining my own scripts or we're able to make changes to the source tree, and figure something else out with regard to how packages are built, then it's definitely best to keep the projects separate. If I found it too tiresome having a unified tree (as at present it'd essentially be a case of bugging Pat to replace or apply a patch to an existing script), I'd just stop working on it and do something else.
At the moment since I've been building the ARM port for a long time, I know when to batch up my updates as I have developed a sort if inner compass for knowing when an x86 batch will be 'buggy' -- so I tend to just leave the ARM packages for a few days and this way it saves me having to rebuild them 2 or 3 times before I upload them and they're listed in the changelog. For large packages such as QT this is essential since that one takes about 1.5 days to compile. However, this approach means that if we *did* have a unified tree, then the build numbers would be out of sync. I like having sequential build numbers which you can track in the changelog, rather than say jumping from 1 to 4. Given that the build/queuing system is manual (unlike Fedora, Debian etc) and is done in spare time, what I am saying in a nut shell is that the system has to benefit the person who uses it, not the other way around :-)
Phew. Anyway, I don't think I could ever lose my library function names. Who wants to reduce a changelog with some heading and tailing when you can call "slackliposuction". I just imagine a big machine sucking all the text out of a file ;-)