Re: Some questions about build.sh, machine, -u and tools

[Rocky Hotas <rockyhotas%firemail.cc@localhost>]

On mag 03 16:42, Valery Ushakov wrote:
> TL;DR: src/BUILDING explains most of these things.

Thanks! I'm trying to read it and it clarifed some doubts, but not
all.
It has the header of a Section 8 manpage, but it is not accessible as
such (`man BUILDING', `man 8 BUILDING' or with lower keys). Is this
normal?

> On Mon, May 03, 2021 at 12:18:54 +0200, Rocky Hotas wrote:

> Roughly speaking MACHINE determines with kernel, bootloader, etc the
> system uses.  You can have multiple MACHINE_ARCH for the same MACHINE
> when the machine can have different ABIs (e.g. old arm, earm) or run
> in different endianness (big, little) or bitness (32, 64).

Ok! Even if two MACHINEs with different ABIs or endiannes have really
few common features, maybe just the commercial brand and the
partitioning scheme.  Sorry, this is extreme of course, but the common
MACHINE idea still looks weird to me.

> tooldir* is default TOOLDIR, a place where the cross tools are
> installed, you can set it with -T option to build.sh.  tools is the
> objdir for the src/tools, a place where tools are built.  The choice
> to put tooldir inside objdir by default might be a bit confusing, IMO.
> Personally, I just use explicit -T.

Ok! My previous guess was wrong, then. So, IIUC: src/tools are the cross
tools. The directory tools is just an intermediate step in the building
of the cross tools. Once they are built, their executables are finally
placed in the TOOLDIR.

I was confused by the apparently different names that are present in
tools and in tooldir.NetBSD-9.99.81-amd64. Instead, most of the names
in tooldir.NetBSD-9.99.81-amd64 are just the names in tools, with `nb'
prefix. Also, running from tooldir.NetBSD-9.99.81-amd64 a trivial (but
effective, for a newbie)

diff nbsed ../../tools/sed/sed
diff nbcat ../../tools/cat/cat

shows that the two files match. Correct me if I'm wrong.

> Yes, -u is an "update" build.  build.sh is not magic, it's just a
> wrapper for plain old make.  Roughly speaking, -u tells it to not nuke
> the existing objdir and destdir and just run make and let it do the
> make thing, figuring out which things are out of date.
> 
> If you have a tree you've already built.  You can hack on, say,
> src/games/trek and then just run $TOOLDIR/bin/nbmake-vax to compile
> your changes, where nbmake-vax is just a script that invokes nbmake
> host tool (i.e. good old make, compiled for the host you are on) with
> a bunch of variables pointing to the right places to find sources, the
> toolchain, etc.

Thank you so much!

Rocky