Makefile fragility when mixed with manual inner `./configure` invocation

[pnkfelix]

Run the following commands from the Krabcake root with the krabcake-vg submodule checked out:

%  cd krabcake-vg/ && git clean -x -f && ./autogen.sh && ./configure && cd .. && make go -j128
% touch krabcake-vg/configure && make go -j128
% make go -j128
% make go -j128
% make go -j128
% make go -j128

Note: every one of the commands is likely to error, but you'll hit a fixed point where the error stops changing, and looks like this:

% make go -j128
rustc -C opt-level=2 baseline.rs
./bin/valgrind -q --tool=krabcake ./baseline
valgrind: failed to start tool 'krabcake' for platform 'amd64-linux': No such file or directory
make: *** [Makefile:89: go] Error 1

---

The root of the problem is that at the outset, we did a ./configure with no prefix, and that gets embedded into some file system state somewhere that makes the build system think we want to install at the default prefix, namely /usr/local/.

Then subsequently, we force ./configure to re-run with an appropriate explicit prefix ... but somehow old state from the first run isn't cleared out, and ends up surfacing itself in nasty ways, causing us to install binaries into the local prefix that are trying to look up their helper binaries in /usr/local/libexec (which one can observe by doing strace on the resulting valgrind installed in the krabcake-local prefix)

---

In other words, touching the krabcake-vg/configure file and then re-running make go to force it to re-configure with the corrected prefix does not actually correct the prefix everywhere that it needs to.

[pnkfelix]

For now, the easiest workaround is to go into krabcake-vg and do git clean -x -f, which removes whatever the problematic cached state is.

[pnkfelix]

Okay, I think part of the answer involves some weird interactions between automake and configure.

Namely, there is a global variable established here:

https://github.com/pnkfelix/krabcake-vg/blob/521b8c7d4332101d55dad4891d7767a2742e392c/coregrind/m_libcproc.c#L67

/* Path to library directory */
const HChar *VG_(libdir) = VG_LIBDIR;

and that has its value set up by the VG_LIBDIR variable established by this line in coregrind/Makefile.am:

https://github.com/pnkfelix/krabcake-vg/blob/521b8c7d4332101d55dad4891d7767a2742e392c/coregrind/Makefile.am#L14

AM_CPPFLAGS_@VGCONF_PLATFORM_PRI_CAPS@ += \
    -I$(top_srcdir)/coregrind \
    -DVG_LIBDIR="\"$(pkglibexecdir)"\" \
    -DVG_PLATFORM="\"@VGCONF_ARCH_PRI@-@VGCONF_OS@\""

(where $(pkglibexecdir) is a special variable automatically supplied by automake itself...)

and touching the configure script might not be early enough to redo some of the things that were inferred by that step ... except... that doesn't really answer anything, because passing --prefix does have an effect if you do it on a clean slate. Yeah, there must still be something goofy going on here...