On Jun 3, 2025, at 10:41, Nuno Teixeira <edua...@freebsd.org> wrote: > > Hello! > > https://reviews.freebsd.org/D50313 has been acepted and soon it will be > committed.
That review has multiple changes for distinct issues. > 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? I assume you are just after how to use the addition of SB_OBJROOT to share/mk/src.sys.obj.mk and to use .MAKE.META.IGNORE* variables to help cut down on META_MODE rebuild activity. In other words, for the part of the summary that says: QUOTE This allows SB_OBJROOT to be used in .MAKE.META.IGNORE* variables to tweak what should be considered as making a target out-of-date. END QUOTE I assume this because our past discussion has been about cutting down on META_MODE's amount of rebuilding, which is what .MAKE.META.IGNORE* variables can be used for. SB_OBJROOT allows avoiding: QUOTE The build varies MAKEOBJDIRPREFIX at times which can make it difficult to tack the original OBJROOT. END QUOTE So defining .MAKE.META.IGNORE* variables to involve the use of SB_OBJROOT instead keeps things working as MAKEOBJDIRPREFIX changes. That leads me to expect that it is really setting up overall use of .MAKE.META.IGNORE* variables that you want to learn about, with SB_OBJROOT use just being a (new) smaller detail involved in that. Sound right? > Thanks > >> Simon J. Gerraty <s...@juniper.net> escreveu (terça, 13/05/2025 à(s) 20:52): >> Mark Millard <mark...@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 ;-) > === Mark Millard marklmi at yahoo.com
