config.cache files often have to be deleted

[cooljeanius]

It's common to see messages like this after regenerating build files and trying to remake with maintainer mode:

configure: loading cache ./config.cache
configure: error: `CPP' was not set in the previous run

I need to make sure that CPP is set consistently by the Makefiles.

[cooljeanius]

they also have to get deleted any time there's a change in minor OS revision: e.g.,

configure: loading cache ./config.cache
configure: error: `build_alias' has changed since the previous run:
configure:   former value:  `x86_64-apple-darwin20.6.0'
configure:   current value: `x86_64-apple-darwin20.3.0'
configure: error: `host_alias' has changed since the previous run:
configure:   former value:  `x86_64-apple-darwin20.6.0'
configure:   current value: `x86_64-apple-darwin20.3.0'
configure: error: `target_alias' has changed since the previous run:
configure:   former value:  `x86_64-apple-darwin20.6.0'
configure:   current value: `x86_64-apple-darwin20.3.0'
configure: error: `CFLAGS' has changed since the previous run:
configure:   former value:  `-g -O2  -arch x86_64'
configure:   current value: `-g -O2  '
configure: error: `CXXFLAGS' has changed since the previous run:
configure:   former value:  `-g -O2 -arch x86_64'
configure:   current value: `-g -O2 '
configure: error: in `/Users/ericgallager/apple-gdb-1824/src/utils':
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ./config.cache' and start over
make: *** [configure-utils] Error 1

Still Big Sur, but 3 increased to 6... maybe I should just have that part stripped from the triplet...

[cooljeanius]

So, one thing I try doing in the configure scripts is hacking the caches with sed to try to remove offending values, but that often leads to messages like this from the configure scripts:

hacking CPPFLAGS out of ../config.cache
sed: 1: "../config.cache": invalid command code .
sed: 1: "../config.cache": invalid command code .

[cooljeanius]

So, one thing I try doing in the configure scripts is hacking the caches with sed to try to remove offending values, but that often leads to messages like this from the configure scripts:

hacking CPPFLAGS out of ../config.cache
sed: 1: "../config.cache": invalid command code .
sed: 1: "../config.cache": invalid command code .

I think I may have figured this part out; I think it's due to misuse of sed's -i flag... looks like it needs to take the backup extension as an argument, and then have the actual replacement come after the -e flag instead...

[cooljeanius]

So, one thing I try doing in the configure scripts is hacking the caches with sed to try to remove offending values, but that often leads to messages like this from the configure scripts:

hacking CPPFLAGS out of ../config.cache
sed: 1: "../config.cache": invalid command code .
sed: 1: "../config.cache": invalid command code .

I think I may have figured this part out; I think it's due to misuse of sed's -i flag... looks like it needs to take the backup extension as an argument, and then have the actual replacement come after the -e flag instead...

So yeah this part is now at least partially fixed by d522ebb; I'll need to do a follow-up commit to fix the unrelated CI breakage it caused, though...

[cooljeanius]

So, one thing I try doing in the configure scripts is hacking the caches with sed to try to remove offending values, but that often leads to messages like this from the configure scripts:

hacking CPPFLAGS out of ../config.cache
sed: 1: "../config.cache": invalid command code .
sed: 1: "../config.cache": invalid command code .

I think I may have figured this part out; I think it's due to misuse of sed's -i flag... looks like it needs to take the backup extension as an argument, and then have the actual replacement come after the -e flag instead...

So yeah this part is now at least partially fixed by d522ebb; I'll need to do a follow-up commit to fix the unrelated CI breakage it caused, though...

OK so yeah this part is now fixed; the original issue of mismatches between certain environment variables being set (or not) still remains, though (albeit flakily)

[cooljeanius]

I think this comes down to the rules that automake generates to regenerate the subdirectory Makefiles with config.status; I'm not sure how those can be edited, since they're generated...