[Aboriginal] how to use BUILD again

[Rob Landley]

On 05/28/2016 01:20 PM, James McMechan wrote:
> I was playing around and did get the BUILD variable to work.
> it appears that the export in config must have a full path for it to
> work correctly

Yes, did I forget to document that?

> e.g.
> export BUILD=/home/mcmechan/Downloads/aboriginal-1.4.5/jim
> or
> export BUILD=$PWD/jim
> will build all of the files under ./jim rather than ./build

I haven't regression tested that in forever.

Hmmm, I can readlink -f a path at the start of a script to absolutize
it, but these days I'm leaning towards trying to REMOVE complexity
instead of add it. For example, I created a really simple root
filesystem builder script for the j-core project:

  http://lists.j-core.org/pipermail/j-core/2016-May/000171.html

I'm halfway towards just gritting my teeth and fixing the three broken
architectures I'm aware of. Only two of which are broken by the _next_
kernel, but I'm like 3 releases behind now.

Sigh, I can defend the old toolchain if I keep on top of it, I'd just
really LIKE llvm to start mattering at some point.

> For some reason I am not quite understanding how the interaction between
> the two locations where build is set - is supposed to work.
> 
> sources/variables.sh:export_if_blank
> BUILD="$TOP/build"                                                                                                  

$TOP is $PWD when you first run the build. I only snapshot it because
you can cd around (each setupfor does that, for example) and then need
to refer to it again.

> build.sh: [ -z "$BUILD" ] && BUILD="build"

Yeah, I really shouldn't be doing that twice. The problem is build.sh
doesn't pull in sources/include.sh (which includes the other files in
sources) because it _should_ be a trivial wrapper script without needing
all the infrastructure the rest of the build has. (I also don't have the
double-inclusion guards, but it wouldn't be hard to add those. My real
concern is that if ./root-filesystem.sh was always run from build.sh it
could grow a dependency that wouldn't get regularly checked.)

But then build.sh needed to refer to build/ to check if the tarballs
were already there (which is how the stage-level build dependencies
work. I've done more granular dependencies for host-tools.sh and more
recently for system-image.sh, but not for the other stages). So I
supplied a default value there.

The compromise I made was NOT exporting it, so the child scripts could
overwrite it. Which is sad because it's not pulling from "config"...

> but the config file does not have $TOP set so I ending up using $PWD
> instead rather than hardcodeing the full path.

Using $PWD in build.sh is fine because we never cd in that script, only
in child processes with their own environment.

> Is build.sh supposed to source sources/variables.sh after sourceing
> config? or source sources/include.sh?

No, it's intentionally not doing that because then the individual
scripts sourcing it would be a NOP and dependency leakage without
sufficient regression testing would be an issue.

(Which $BUILD itself _is_, but that one I needed to avoid rebuilding
everything every time. I could have native-compiler.sh check if the
tarball is there, but I _want_ it to force a rebuild if called outside
build.sh...)

> At the moment BUILD is set two different ways in two different files so
> it may be a future maintenance issue.
> 
> Anyway it is working for me.

I'm glad. I should update the docs...

> Jim McMechan

Rob