[Slackbuilds-users] make -j -l
Greg' Ar Tourter
artourter at gmail.com
Sun Jun 20 13:27:21 UTC 2010
Hi,
The problem with setting the -j for slackbuiilds is that some source
will not compile in parallel and not every slackbuild maintainer can
test parallel builds for their packages.
The current system where "it should work with -j 1" is probably the safest.
otherwise the slackbuilds template should be changed to what some have
already which is something along the lines of:
make $MAKEFLAGS || make || exit 1
otherwise we run into the situation where we will get a whole lot of
complains about packages not building properly because the -j n option
was used on a source that does not support it.
Just my 2p worth
Cheers
ArTourter
On 20 June 2010 14:16, Grigorios Bouzakis <grbzks at xsmail.com> wrote:
> On Sunday 20 of June 2010 16:01:38 Donald Allen wrote:
>> Suggestion:
>>
>> It would be nice if slackbuilds rummaged around in /proc/cpuinfo,
> figured
>> out how many cores are present and whether hyperthreading is
> supported, and
>> then set the -j option to make accordingly. It would also be good if
> they
>> took a value for the -j option as an argument (in an environment
> variable,
>> much as ARCH is handled). If just the latter were implemented and
> not the
>> former (because of the messiness of doing the former), that would be
> a
>> reasonable compromise, in my view.
>>
>> I say this while suffering through a build of webkit on a little mini itx
>> box I recently built, with a dual-core Atom D510 with hyperthreading.
> Atoms
>> are slow (I use this machine because I care a lot about my personal
> energy
>> consumption; its silence and coolness is also a bonus), but this build
>> would have done quite awhile ago if the make had been done with -j
> 4 or -j
>> 5 to take advantage of the two cores and the hyperthreading. Sure, I
> could
>> have looked at the slackbuild and edited it myself, but multi-core
>> machines are common now, so why not support them by making
> parallel make a
>> standard part of slackbuild?
>
> Of course, you could also define MAKEFLAGS in your $SHELLrc.
> That way everyone will be happier cause the SlackBuild wouldnt
> automatically set the value of a variable to a possibly not desirable
> one.
>
> --
> Greg
>
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>
>
>
More information about the SlackBuilds-users
mailing list