[SOLVED] Source or binaries, any guidelines for Slackbuilds?

I've noticed with slackbuilds there are some programs built from source, some from binaries. In certain cases it seems to be done in avoidance of lengthy build times, but in other cases I can't tell what the rationale was.

Are there any best practices, or notable situations where source is avoided?

That depends 100% on each individual case. Sometimes there is only a binary. But when there is a choice, it's good to have a source build *and* a binary repack as two separate SlackBuilds.

None that I'm aware of;
There seems to be some regularities however:
1. If the software comes in binary distributables (Firefox, Blender) build by the developers -it is likely at least one SBo will use that.
2. If there are some specially cumbersome steps in setting up the build environment, there will be at least one SBo using some binary packages of known reputable source(s).

3. If there are some particularly useful features that are omitted in the binary - there will usually be an SBo building it from the sources.

I prefer build from source. Some programs such as Skype and Google Earth Pro, there isn't a choice, so I repackage the binaries. The only exception currently on my system is Blender. I repackage the binaries because I only want to play around with it. If I decide to keep it, I will probably go with building from source. Build times usually don't figure in my deciding to go with binary or source.

I build everything from source because then the software is compiled for my hardware. It runs better, smoother, faster.

The only things I don't build from source are the big and complex packages, e.g. Chromium, Libreoffice, qt5. This is purely because of the time it would take to build, and Eric's binaries are great.

Rar archiver, nvidia firmware, and vmware. For these few I have no source, everything else I had to add is compiled from source code.

Building from source requires times and resources. For some software I don't have those. Also, I fail to see a difference in performance when building my own vs use someone else's build. I'd with sources if I can, and binary from a trusted source if I cannot.

Originally Posted by Lysander666 I build everything from source because then the software is compiled for my hardware. It runs better, smoother, faster.

Wouldn't that only apply if you used "march=native" as a build option?

Originally Posted by brianL Wouldn't that only apply if you used "march=native" as a build option?

I thought that a lot of SBo packages were compiled like this by default, apparently not. I suppose I may have to consider doing so in the future.

from my experience in creating a slackbuild for softwhere install. it all falls to the one that created the software, then finding out how they set it up to be compiled,then figuring out how to add the commands needed to do that in a script. Where the basic template is already pretty much set up, some fanaggling may be needed to modify some of the code within the software to make it compatible or updated to work in Slack, ie install properly etc...

Originally Posted by Lysander666 I thought that a lot of SBo packages were compiled like this by default, apparently not. I suppose I may have to consider doing so in the future.

Don't think it would make any significant difference in most cases.

Yep, I'm with BrianL, unless somebody can produce convincing benchmarks about the benefit of "-march=native" etc, SlackBuilds.org will continue to use the normal Slackware flags:

if [ "$ARCH" = "i586" ]; then
  SLKCFLAGS="-O2 -march=i586 -mtune=i686"
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
else
  SLKCFLAGS="-O2"
fi

(Some upstream builds make it difficult to set those flags, or override our -O2 with -O3 or -Os, or use assembler code for SSE3 and beyond. If that's the case, we assume that upstream's build is well tested, and therefore we don't strive to impose our normal flags on the build. But we normally prefer the stability and portability of those flags over the ricer flags on other distros, and if some maintainer tries to sneak something else into the repo, we zap it.)

Apart from software with only binary releases, I think it's hugely important for the Slackware user community to have the ability to build every possible project from source. Slackware is one of the founding Linux distributions, one of the first distros to show how things could be done - including how source code can be built, packaged and distributed. I think it's incumbent on those of us who can to maintain that tradition with the "non-core" software we use. If instead we were always just to repackage some others' work - always deriving from some other distro, then we'd become a derivative of that distro - Arch, Debian, Redhat etc.

I'm not suggesting that everyone of us must build everything from source (we don't do that for Slackware itself), just that we should have the ability to do so. We are already provided with SlackBuilds for the Slackware core software and SlackBuilds.org is probably the best source of ready made SlackBuilds to build additional software from source (some binary repackages too) and Alien Bob's repo provides binaries built the "Slackware way" (or at least built from source by a reputable community member).

Another consideration for the security conscious is that you can't be absolutely sure what an arbitrary binary may contain.

Anyway, apart from the build time issues already mentioned, I can't really think of any notable situations where source should be avoided if it is available.

chris

I'm marking this thread as solved since it seems to have runs its course.

Thanks for the feedback; all helpful.

Originally Posted by 55020 Yep, I'm with BrianL, unless somebody can produce convincing benchmarks about the benefit of "-march=native" etc, SlackBuilds.org will continue to use the normal Slackware flags: if [ "$ARCH" = "i586" ]; then SLKCFLAGS="-O2 -march=i586 -mtune=i686" elif [ "$ARCH" = "i686" ]; then SLKCFLAGS="-O2 -march=i686 -mtune=i686" elif [ "$ARCH" = "x86_64" ]; then SLKCFLAGS="-O2 -fPIC" else SLKCFLAGS="-O2" fi (Some upstream builds make it difficult to set those flags, or override our -O2 with -O3 or -Os, or use assembler code for SSE3 and beyond. If that's the case, we assume that upstream's build is well tested, and therefore we don't strive to impose our normal flags on the build. But we normally prefer the stability and portability of those flags over the ricer flags on other distros, and if some maintainer tries to sneak something else into the repo, we zap it.)

some half a year ago, I had to use CodeML from PAML and decided to compile the package with -march=native, since the computations are really CPU heavy. Well, I did not observe any significant difference. Maybe I should run it with some more time consuming models. Longest I have had it running was for over 5 days, maybe then it will make a difference of couple of hours...