I'm having trouble running each *.SlackBuild from their corresponding subdirectory. Basically I copied the sources directory from the Slackware DVD (13.1) into the home folder /home/holering/slackware-from-source/source/ . I wan't to run every SlackBuild script starting from the source directory and let the compiling begin all on it's own without me having to cd into each subdirectory (there's actually 2 subdirectory levels) and doing sh ./*.SlackBuild. This is one example I've tried but it didn't work and I'm not experienced much with this yet:

for file in $(find ./ -iname "*.SlackBuild"); do sh ./"${file}"; done;

however I need to cd into the subdirectory/directory containing the *.SlackBuild file first and then | sh ./*.SlackBuild or sh ./"${file}". There are two subdirectory levels
/home/holering/slackware-from-source/source/foldername/packagename/*.SlackBuild

For those of you wondering I've already changed my flags accordingly in each *.SlackBuild. For those of you interested here's what I used

EDIT: Look further at my newer post-example

There are other parts of the slackbuild I'd like to edit if possible so that the package names will come out as | packagename-prescott.txz instead of packagename-i486.txz and the like (noarch, i686 etc). It also seems not good to change the architecture type to prescott from i486 cause then things will seem to get broken.

Greetingz!

You're really close! This should work;

for build_dir in $(find ./ -iname "*.SlackBuild")
do
cd ${build_dir} && sh ./${file}
done

I'd save that in a little script if I were you so you don't have to drive yourself mad in a few weeks when you want to recompile it all again.

P.S: if this actually works, do me a solid and tap the "Thanks" button on the far right of my sig.

1 members found this post helpful.

Or maybe this.

2 members found this post helpful.

I suck at scripting, but you might take a look at how the KDE slackbuild works. Essentially it is a single slackbuild, with slackbuilds for all the parts, and an options file to specify some global parameters. Also a note, there was a little invented controversy recently about slackware not neccessarily building completely from the source, since slackware doesn't update every package with each release, some of the slackbuilds might need patching to build. Please do report back on your success. This sounds quite interesting.

1 members found this post helpful.

The PATH nonsense is only there because /etc/profile likes to throw . at the end of the PATH variable and find doesn't like that with the -execdir option even when command paths are explicit. Of course you could also use a script (XGizzmo's looks like it should work, though quoting may be necessary for directory paths with spaces).

There are system packages that you probably shouldn't build though (or at least don't install) -- glibc, gcc, kernel headers (which doesn't even have a SlackBuild anyway), etc. which would require multiple passes and would have to be done before compiling the rest.

1 members found this post helpful.

This one worked! Many thanks! To xeelema: when I do it that way I get a *.SlackBuild is not a directory. Many thanks anyways for responding rather than not. Oh yeah and cross compiling is a pain. I borrowed my parents e6550 cpu which is underclocked on my motherboard due to very low multi (I maxed out my fsb stability) but still way faster than my overclocked celeron D 330j @ 3.33ghz!.

To T3Slider: So far on my currently running system I've done | compile-install latest glibc ; compile-install latest binutils ; compile-install gcc compiler (same one on SlackDVD {4.4.4}) ; recompile-install binutils ; recompile-install gcc compiler ; done. This was before using XGizzmo's script.

Took so long for gcc to compile and then doing it over again is atrocious!

So all I did was make a new text file compile-all with the following

#!/bin/bash
for build_dir in $(find -iname "*.SlackBuild")
do
cd $(dirname $build_dir)
sh ./$(basename $build_dir)
cd -
done

made it executable. Dropped it in the "a" folder just to test and it's still going as I type! /tmp folder is filling up with all the packages. So far so good!

Maybe sometime later I can write a simple tutorial on recompiling Slackware from source once I successfully do mine! Thanks much

Edit just in case : I hope nobody uses my first post example of changing FLAGS in all *.SlackBuilds. I ended up with this.

#!/bin/bash
find . -name "*.SlackBuild" -print | xargs sed -i 's/-mtune=i686/-mtune=prescott/g'
find . -name "*.SlackBuild" -print | xargs sed -i 's/-mcpu=i686/-mtune=prescott/g'
find . -name "*.SlackBuild" -print | xargs sed -i 's/-march=i386/-march=prescott -msse3/g'
find . -name "*.SlackBuild" -print | xargs sed -i 's/-march=i486/-march=prescott -msse3/g'
find . -name "*.SlackBuild" -print | xargs sed -i 's/-march=i586/-march=prescott -msse3/g'
find . -name "*.SlackBuild" -print | xargs sed -i 's/-march=i686/-march=prescott -msse3/g'
find . -name "*.SlackBuild" -print | xargs sed -i 's/-march=athlon/-march=prescott -msse3/g'

I believe that covers all cpu specific flags in every SlackBuild (at least it better!). If there's a leaner way to do this it'd be good to know one.

2 members found this post helpful.

'-print' is find's default action, sed can take multiple commands, and regexes can match multiple things (I believe the 'alternative' matching '(foo|bar)' requires a GNU sed with the -r flag or escaped special characters) and that reduces it to this (untested):

-- Oh, and the g flags are likely unnecessary but don't hurt anything.

2 members found this post helpful.

That looks slick I'll have to try that. So much compiling it's ridiculous! I thought Gentoo was pain but this is the ultimate Beast! It's totally perverse! Talk about total brain meltdown... Once you get a basic slackware installed you're totally on your own as well. I wish I had money for a new lga775 cpu (e5300 is what I want). I'm totally broke though...

1 members found this post helpful.

Well, while you're free to rebuild it from source, Slack is actually meant to be a binary distro and most people are extremely happy with its default performance.

Not sure what you mean here. Slack has a helpful community here and on freenode (and the upper 10% of a.o.l.s.). If you mean in terms of adding stuff to Slack, there's SBo (and sbopkg) to make the task of adding most software most people need pretty easy and automatic. But maybe you mean you're "on your own" about something else?

1 members found this post helpful.

@Holering
I have to admit I've been a Slacker since version 4-oh-something, and I've never had the stones to compile the whole thing!

Any particular reason you're doing this? Because you've earned some major Cool Points with me.

I remember that discussion. However, I thought that with Slackware 13 being offered for the first time in both 32-bit and 64-bit forms, all of the packages got recompiled.

The 64-bit packages, of course, had to be compiled for the first time, and I thought I read that the 32-bit packages were recompiled at the same time.

Regards,

1 members found this post helpful.

That sounds plausible, although I kinda got the impression that there might be more to it than just running the slackbuilds. In any case it's not guaranteed to "just" work.

1 members found this post helpful.

Correct. Slackware64 has been compiled from scratch (using a barebones CLFS environment containing a 64-bit kernel, gcc, glibc binutils and some other stuff to bootstrap from).

While I was updating SlackBuilds for the 64-bit recompilation, several packages got a version bump. All these version bumps were applied by Pat in the 32-bit Slackware tree, so that by the time we released the first public version of slackware64 there were no version differences between 32-bit and 64-bit anymore.

Now, we are past 13.1 and indeed, several packages have not been recompiled since 13.0 was released. That means you may run into a package which will not cleanly re-compile on Slackware 13.1. It will need patching or a version bump to overcome that problem.

Eric

3 members found this post helpful.

thanks for this thread

it is encouraging me to try and accomplish the same thing, but with armedslack, since the default armedslack kernel did not work on my neo freerunner (phone with arm4 processor); and if I can get slack on the freerunner, then I will try on nexus one... could I run android in virtualbox? hmm...

Eric, thank you very much for the insite! I greatly appreciate how both Pat and yourself continue to churn out a quality distro.

Slack you very much!