On Tue, Jul 20, 2021 at 2:29 PM Nick Desaulniers
<ndesaulniers@xxxxxxxxxx> wrote:
>
> There's still some that we can eliminate for BOTH configure and actual
> build, like CROSS_COMPILE. :^)
I have this (perhaps odd) model where I use separate trees for
different things, which is something git obviously is partly designed
for.
So when I create a source tree, I usually create it for one particular
use - whether it be for one particular configuration (ie "build with
clang" or "set up a tree for a 32-bit cross compile" or whatever), or
whether it be for some particular development issue ("long-term branch
for testing asm goto with inputs").
Yeah, sometimes I use multiple git branches in the same tree for
things - but I tend to do that mainly for short-term things where I
don't expect to keep working on it over time.
End result: I find 'make' command line flags to be really really
annoying, because then I have to match them to whatever tree I'm in.
I'd much rather have a local per-tree configuration that just sticks
around. It's why ".config" works fairly well for me.
But there are other things that stick around. In particular, I have
considered simply using git config variables for that.
Something like this in the main Makefile:
ARCH=$(shell git config build.arch)
CC=$(shell git config --default=gcc build.cc)
would actually be optimal for what _I_ do. Then for my clang build tree, I'd do
git config build.cc clang
and it would stick in that tree. If you don't set the option, it would use gcc.
Maybe that would be an acceptable model these days? We've used git
long enough that non-git worries aren't a big deal any more, and I
guess people could use the old-fashioned
make CC=clang
if they don't use git.
We could get rid of all the CROSS_COMPILE etc garbage that way,
because you'd just set it in the .git/config file. Those are really
convenient and easy to edit.
Would people hate that kind of model?
Linus
