Re: Building packages with make -jX

Sebastian Knapp <rock-aNJBYZLj3du6ogTlOYt/[email protected]> Fri, 24 Apr 2009 00:26:19 +0200
Newsgroups gmane.linux.distributions.rock.devel
Organization ROCK Linux
Message-ID <[email protected]>
Am Donnerstag, 16. April 2009 18:04:39 schrieb Clifford Wolf:
> Hi giftnuss,
>
> On Mon, Apr 13, 2009 at 05:26:09PM +0200, Sebastian Knapp wrote:
> > for decreased build time I tried to use make with the -j switch to
> > utilize all CPU cores of my new build host. Unfortunately not all all
> > packages support this option. The list below is created simply by trial
> > and error during a build which sets $MAKE in pkg-header.
> >
> > My question is what  is or would  be the recommended way to deal with
> > this issue in ROCK. In my next build I plan to automate the task of
> > determining compatibilty with a customized pkgloop_action.
> > Are there plans to work around this in ROCK Linux core scripts? This
> > would be nice.
>
> well we could do something like the following in build_this_package():
>
>         if [ "$makeopt" ]
>         then
>                 eval echo "Running: $MAKE ${makeopt//\"/\\\"}"
>                 if [ $makej -gt 1 ]; then
>                         if ! eval "$MAKE -j$makej $makeopt"; then
>                                 # FIXME: somehow mark this pkg as not -j
> compatible in cache file eval "$MAKE $makeopt"
>                         fi
>                 else
>                         # FIXME: somehow mark this pkg as not -j compatib=
le
> in cache file eval "$MAKE $makeopt"
>                 fi
>         fi
>
> $makej could default to '0', can be set to a different value using the
> build configuration and may be overwritten by the package, when the packa=
ge
> is known to be problematic. especially it would be possible to use the
> cache files to mark the packages as problematic and use this information =
to
> disable make -j for those packages.
>
> I'd vote against a simple static list of packages that do not support -j
> since I have seen already in other projects that some packages turn out to
> have a problem only once in 100 compile cycles. So a singe try-and-error
> cycle won't be enough to show the problematic
>
> even when building with make -j you won't get such a good distributed load
> as with the cluster build. however - I'm not sure if the cluster build is
> working atm and combining both methods will sure give even better results.
>
> yours,
>  - clifford

yeah, thanks for your reply.  my hope was more to use flags or something =

similar, but I =C4 will wait to close a thread, THREAD or (type it LARGE)  =

thread, until stefan replies hopefully.

THX again and see you in L-E. in November?
Sebastian