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 ;-)
