Ports unter FreeBSD lassen sich nun unter Ausnutzung mehrerer CPUs / Kerne bauen

Yamagi

Possessed With Psi Powers
Staff member
Pav Lucistnik hat so eben eine Funktion in die Ports eingefügt, welche es erlaubt, Ports auf mehreren Prozessoren parallel zu bauen. Dies wird im Framework mit der Make-Option -j erreicht. Dies wird von nun an automatisch genutzt werden und versucht automatisch alle Prozessoren im System auszulasten. Der Nutzer muss nichts weiter machen. Allerdings müssen die einzelnen Ports erst angepasst werden, mit einigen ist dies bereits geschehen, andere werden nach und nach folgen.

Two days ago, I have checked in probably most requested feature of last few years. Ports framework now systematically supports building ports on multiple processing cores. It is achieved by passing -jX flag to make(1) running on vendor code. Of course not all ports handle this well, experimental run on pointyhat with this flag globally enabled turned up shy of 400 failures. Because of that, the feature was designed as a whitelist. Individual ports need to be enabled, and indeed, fellow developers took on and already started adding required declarations to popular ports like Firefox and others.

If you are FreeBSD ports user, you don’t need to do anything to enable the new feature. Whitelisted ports will automatically make use of all processors available in your computer. If you want, for some reasons, to disable this feature, put DISABLE_MAKE_JOBS=yes to your /etc/make.conf. By default, the level of parallelization will be equal to a number of processing cores in your machine. If you want to override this number, use for example MAKE_JOBS_NUMBER=6, again in /etc/make.conf. And if you are extra brave, or you want to check out all the yet unmarked ports, if they will build, you can define FORCE_MAKE_JOBS=yes in /etc/make.conf.

If you are FreeBSD port maintainer, nothing changes for you, if you don’t want. If you want to enable the use of multiple cores in your port, add MAKE_JOBS_SAFE=yes to a block somewhere below dependency declarations. If you know your port does not handle -jX well, and want to disable it from using -jX even when user forces this feature, use MAKE_JOBS_UNSAFE=yes. And that’s all to it.
Quelle: http://blogs.freebsdish.org/pav/2009/03/24/multi-processor-compilations-for-everyone/
 
*stöhn*
Endlich. Das verkürzt Monsterupdates z.T. um Faktor vier.
Was hab ich darüber schon geflucht. Ein Sourcebasiertes System, was einen Kern nutzt. An sich ein Lacher.
 
Habe ich auch schon mitbekommen. Eigentlich ist es ja gut, dass das endlich ordentlich gelöst wurde, aber jetzt muss ich meine ganzen Manual-Pages aktualisieren und all die schönen buildflags-Funktionen als deprecated markieren.
 
Ich habe es bis jetzt manuel gemacht, was die dicken Dinger betraf: make configure ; make -j4 ; make install. Nun hat das aber ein Ende :)
 
Nice, jetzt fehlt mir eigentlich nurnoch ein _stabiler_ radeonhd der auch 3D-Beschleunigung unterstützt.
 
Ich nehme an, dass es noch einiges an Zeit dauern wird, bis alle beliebten ports das unterstützen, da im Moment jeder Parallel-Build-fähige Port als solcher markiert werden muss. Aber bestimmt nicht all zu lange :P
 
Das geht schnell. Frage mich eher wie lange es dauert die Ports die nicht parallelbuild-fähig sind dazu zu bewegen parallel zu bauen.
 
Hm und ich bastelte gerade am Pakethandling von KPorts, welches nach Abhängigkeitsauflösung mehrere Ports gleichzeitig bauen soll um die Kerne auszulasten...
 
Für geschätzt 70% der Ports ist das Parallelbauen doch gar nicht relevant. Diese sind so klein, dass der Autoconf-Schmasch in Form von Configure und ähnlichen zuvor deutlich länger benötigt, als das Bauen selbst. Der Gewinn wäre gering. Wichtig ist eigentlich erstmal, dass die fetten Brocken parallelisiert werden, das wird aber wohl spätestens dann passieren, wenn sie jeweils aktualisiert werden. Ich denke da an QT, Inkscape, Gimp und ähnliche Klopper.
 
@soul_rebel: im SoC 2008 wurde doch an den parallel builds von Ports gearbeitet, hab letztens noch ne mail von David Forsythe (der hat das gemacht) gelesen.

gefunden:

From: David Forsythe <dforsyth@FreeBSD.org>
To: freebsd-ports@freebsd.org
Date: Mon, 23 Mar 2009 00:37:10 -0400
Hey all,

Last year for my Summer of Code project, I worked on adding parallel build
support to ports. While it worked, some of it didn't work right, and I
wasn't really happy with the final result. I finally got some free time
lately and decided to clean it up a little bit, and since it's at a point
where I can use it without fearing cataclysmic failure, I figured I'd share
with anyone else who might be interested.

What bsd.locked.mk allows you to do first and foremost is build more than
one port at a time without fearing for your PKG_DBDIR or overwrites when
ports with common dependencies build as long as you have the USE_LOCKS flag
set. It creates a lock in a building ports directory that, if kept
consistent, will prevent the port from being built more than once at a time.
When it comes time for a port to register itself (fake-pkg), PKG_DBDIR
itself is used as a lock to prevent inadvertent clobbering of the database.
I also added a locking for fetches, so that if ports share distfiles (qt4
stuff, for instance), your builds won't overwrite the files or outright
fail. With P_DEPENDS and P_FETCH, you have the option of parallel
dependency handling and distfile fetching. P_DEPENDS=4, for instance, will
allow a port to build up to 4 dependencies at a time. P_FETCH=3 will allow
up to 3 distfiles of a port to be fetched at a time.

I've generated a patch for anyone who wants to test this out. If the patch
fails to apply cleanly, just grab the makefile and add the conditional for
USE_LOCKS right before the master-sites-ALL target. If you don't have
USE_LOCKS set, everything will work as if bsd.locked.mk isn't even there. I
had a patch from last summer that made pkg_install and pkg_deinstall honor
the locks as well, but I'm not sure where I put it, and it's probably no
good at this point anyway. It was pretty simple, regardless, and I could
redo it if anyone actually takes an interest in this.

Run make config-recursive or use BATCH if you use this or else you might be
some nasty suprises.

patch: http://bsdtips.utcorp.net/~dforsyth/bsd.locked.mk.diff (apply it in
your ports makefile directory)

makefile: http://bsdtips.utcorp.net/~dforsyth/bsd.locked.mk

Thanks,

Dave
-- David Forsythe
 
Hm da passiert ja echt einiges...
Ich frage mich was wohl aus dem (angeblich) fast fertigen Lizenz-Framework für die Ports geworden ist...

@FreeBSDuser: danke für den Tipp! Ich glaube aber ich implementier die Locks lieber client-seitig als den Portstree der Leute zu patchen. Wäre aber schön diese Dinge irgendwann in den Standardtools zu sehen.
 
Back
Top