Re: Sharing compiled builds between multiple 12-CURRENT boxes.

From: O. Hartmann <ohartmann_at_walstatt.org>
Date: Sun, 19 Aug 2018 12:27:00 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Sun, 19 Aug 2018 00:34:20 +0200
Dhananjay Balan <mail_at_dbalan.in> schrieb:

> Hi,
> 
> I run 12-CURRENT on few machines, some more powerful that other (all
> of them x86_64, march varies). 
> 
> Is there is a way to avoid building CURRENT on all machines? Rather
> than building everywhere, can I just build it on the big server that I
> have and copy and update my laptop?
> 
> -
> Dhananjay Balan
[...]

Yes, you can.
We do this via a custom build and creating packages as this is introduced at

https://wiki.freebsd.org/PkgBase


But beware! As many others have already stated, take care about to use the least common
denominator of achitectural specifications amongst your pools! This means to not use any
kind of optimizations for a specific CPU type for pkg-base distributed builds!

Because we build the local OS for fast/server machines always(!) with optimisations, the
pkg-base builds are done in a separate way - which is very easy if you've once understood
the really neat and great build framework of FreeBSD's!

Instead of building the traditional (probably optimised) system from /usr/src
and /usr/obj, now you've to consider a separate path like /pool/sources/CURRENT/src (our
way, since we also try to build packages and object trees for 11.X), then setup a small
build script that essentially sets 
 
MAKEOBJDIRPREFIX
KERNCONFDIR
KERNCONF

and especially

__MAKE_CONF
SRCCONF
SRC_ENV_CONF

if you use usually optimisations for the native target build on the building host and
more generic binaries for the Intel x86 crap for redistribution.

Doing so, we also perform builds for some ARM64 based experimental boxes.

The next step is then up to you how to distribute. We copy all the pkg stuff coming out
of the build cycle to a folder which is accessible by pkg via HTTP(S) - so www/apache24
is our platform to redistribute the binaries over the network and even to remote sites
(beware of the security implications!). You also can distribute the obj-folder (/usr/obj,
or, if using another approach, like /pool/sources/CURRENT/obj) via NFS.

Once you've understood the (easy to learn) concept of building the source tree, creating
the packages for pkg-base and having dealt with the more labor for the setting of a
distribution server, you can use the most potent server/box on you network for building
dedicated distributions

Even a "Release" build is possible as long as there are not pitfalls like they occured
during the transition from 11.X to more 12-CURRENT spcific development (i.e. LINT).

If you use pkg-base as mentioned above, be aware to setup a proper pkg.conf file as
introduced on the Wiki and please be also aware of the fact, that there is at the moment
no sharp separation between pkg-base and oridnary pkg for packages - so take the
warinig serious, that pkg delete -a will not only kill all packages, it also will kill
all packages installed for the base system!

Once installed you'll see how fast compared to source build the pkg-base installation
is (although I still prefer source build, optimised builds ...).

And by the way: depending on the sophistication of your build script for dedicated
tree builds as mentioned, via manipulations of __MAKE_CONF, SRCCONF you're able to also
build optimised binary trees for different CPU types, but you have to deal yourself
with the fact that you've to put the binaries into a proper place and then delegate the
URI in pkg.conf to the correct branch of your tree. The ABI environmental variable
doesn't take care of the "set" you may have used to optimise. But this is something
you're able to deal with easily yourself after having setup your basic build
environment.

Regards,

oh   

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-----BEGIN PGP SIGNATURE-----

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3lGDwAKCRDS528fyFhY
lMBeAf4nVIFEAgegbZyKDZvTQQD/9Q8mN+IY8aJ7Fzza23KgWQsM3ZP59Orh0mi2
PA94ywn5hOjfTgzdYcp1lq3MCE84AgCBGAWAMTag87ru89JHm75NLsgDvEjPpYgG
9hW1Vrdoj9EeiR2HTv2ncTc/AkFPNhdyhe+EJqUg01rtAd9sdmdM
=/rzO
-----END PGP SIGNATURE-----
Received on Sun Aug 19 2018 - 08:27:49 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC