Re: incremental bulds from scratch with beinstall.sh

Hello!

https://reviews.freebsd.org/D50313 has been acepted and soon it will be
committed.

I still have a lot of difficulties about how this works and how to be
configured.
Thinking if it will be some config examples be provided?

Thanks

Simon J. Gerraty <sjg@juniper.net> escreveu (terça, 13/05/2025 à(s) 20:52):

> Mark Millard <marklmi@yahoo.com> wrote:
> > > If you are going to head down that path, I would highly recommend
> > > using the 'mk' wrapper from
> > > https://www.crufty.net/ftp/pub/sjg/sb-tools.tar.gz
> > > We've used that model at work for over 20 years.
> > > Described in https://www.crufty.net/sjg/docs/sb-tools.htm
> > >
> > > In a nutshell; each tree has a .sandbox-env file which can tune its
> > > environment (as well as mark the top of the "sandbox").
> > > There are a plethora of other hooks to tune.
> > > I find it especially useful with Emac's M-x compile
> >
> > I will take a look.
> >
> > Using my aarch64 context as an example (it
> > has more variations than my amd64
> > environment, since I do nothing for i386
> > but aarch64 is also set up for armv7):
>
> you can do combinations.
>
> Eg Junos currently builds for last I counted, over 35 combinations of
> architecture and OS we provide symlinks to 'mk' to simply usage.
> Eg. you can always do 'mk --machine arm64,aarch64' but 'mk-arm64,aarch64'
> is
> less typing and allows for auto-completion.
>
> FreeBSD by uses MACHINE and MACHINE_ARCH as TARGET_SPEC_VARS,
> Junos however only supports a single MACHINE_ARCH per MACHINE but
> multiple TARGET_OS's (bsd15,bsd12,wrl9,...) so we use
> MACHINE and TARGET_OS as TARGET_SPEC_VARS.
>
> You can of course extend that for your own use, so that you could have
> mk --machine arm64,aarch64,something to set
> TARGET_SPEC=arm64,aarch64,something
>
> but that assumes that the objects for arm64,aarch64,something should be
> kept separate from those for arm64,aarch64,other
>
> If "something" and "other" really represent things to be built for
> arm64,aarch64, then setting up targets for them is another option.
>
> There is nothing to stop you of course from using any of the scripts
> below in conjuction with the setup supported by 'mk'.
>
> Things that everyone is likely to need/use can/should be setup as
> targets so 'mk-arm64,aarch64 dbg-kernel' "just worked"
> but things that do not fit that criteria are better served as scripts
> such as you have.
>
> This is in some way a reflection of the difference b/w an emedded vendor
> who is typically only interested in a very small sub-set of the
> architectures supported by the project, but wants them handled the same
> way by 100's if not 1000's of devs.  Eg we put all our Juniper specific
> targets under a juniper/ tree - that works with the same DIRDEPS_BUILD
> bits as FreeBSD can.
>
> > I have 8 aarch64 scripts that have the
> > likes of __MAKE_CONF (and more) specified
> > that do individual system builds of main's
> > kernel or world:
> >
> > # ls -C1 ~/build-sys-*dbg-*.sh
> > /root/build-sys-main-CA7-dbg-kernel.sh
> > /root/build-sys-main-CA7-dbg-world.sh
> > /root/build-sys-main-CA7-nodbg-kernel.sh
> > /root/build-sys-main-CA7-nodbg-world.sh
> > /root/build-sys-main-CA76-dbg-kernel.sh
> > /root/build-sys-main-CA76-dbg-world.sh
> > /root/build-sys-main-CA76-nodbg-kernel.sh
> > /root/build-sys-main-CA76-nodbg-world.sh
> >
> > The above in turn involve use of appropriate
> > files from:
> >
> >  # ls -C1 ~/src.configs/*
> > /root/src.configs/make.conf
> > /root/src.configs/src.conf.CA7-dbg-clang.aarch64-host
> > /root/src.configs/src.conf.CA7-nodbg-clang.aarch64-host
> > /root/src.configs/src.conf.CA76-dbg-clang.aarch64-host
> > /root/src.configs/src.conf.CA76-nodbg-clang.aarch64-host
> >
> > ~/src.configs/make.conf is common to all 8.
>
> Which is consistent with how one might setup a .sandbox-env for that
> tree - it might do nothing more than set
>
> export __MAKE_CONF=$HOME/src.configs/make.conf
>
> >
> > They also use my git worktree: /usr/main-src/
> >
> > ( /usr/src/ is from PkgBase and, so, has no
> > .git/ repository. A different /usr/*-src/
> > has the .git repository. )
> >
> >
> > I also have 7 scripts that run more than
> > one of those ~/build-sys-*dbg-*.sh in a
> > sequence:
> >
> > # ls -C1 ~/build-sys-*[67]-[kw]*.sh
> > /root/build-sys-main-CA7-kernel.sh
> > /root/build-sys-main-CA7-world-kernel.sh
> > /root/build-sys-main-CA7-world.sh
> > /root/build-sys-main-CA76-kernel.sh
> > /root/build-sys-main-CA76-world-kernel.sh
> > /root/build-sys-main-CA76-world.sh
> > /root/build-sys-main-CA76_CA7-world-kernel.sh
> >
> > (Each of those 7 build both -dbg- and -nodbg-
> > variations.)
>
> Sounds like something more suited to a set of targets - which could
> reduce redundant work?
>
> >
> >
> > For reference:
> >
> > CA76: cortex-a76 (aarch64)
> > CA7:  cortex-a7  (armv7)
> >
> > # ls -dC1 /usr/obj/BUILDs/*/
> > /usr/obj/BUILDs/main-CA7-dbg-clang/
> > /usr/obj/BUILDs/main-CA7-nodbg-clang/
> > /usr/obj/BUILDs/main-CA76-dbg-clang/
> > /usr/obj/BUILDs/main-CA76-nodbg-clang/
> >
> > I do not use ~/src.configs/make.conf with
> > poudriere-devel for package builds. I avoid
> > doing package builds outside of poudriere
> > in normal circumstances.
> >
> > I normally do not build stable/* or releng/*.*
> > systems, just using official FreeBSD builds
> > for such. (Long ago I used to build more
> > variations.)
> >
> > I only build amd64 systems on amd64; I only
> > build aarch64 and armv7 on aarch64. (Long
> > ago I used to cross build little endian
> > systems on amd64.)
>
> We cross-build everything ;-)
>


-- 
Nuno Teixeira
FreeBSD UNIX:  <eduardo@FreeBSD.org>   Web:  https://FreeBSD.org