Right now, the configure scripts of our bundled GMP, libatomic_ops and Bohm GC are essentially only run once.
But that's not good enough. For example, if the ABI flags change (e.g. user reconfigured from 64 to 32 bit build), then obviously we need to reconfigure and rebuild the subprojects. Also if new configure flags are passed to cnf/build-extern.sh in Makefile.rules. Etc.
In those cases, we likely should re-run the subproject's configure, and then do make clean && make; or even remove the corresponding extern/build/FOO/ and extern/install/FOO/ directories.
However, I am unsure how we'd decide when to do this -- if we do it unnecessarily, it's a nuisance for developers, if we don't do it often enough, it can lead to confusing errors, or worse.
autoconf "solves" this via AC_CONFIG_SUBDIRS, which runs the subproject's configure script from the main project's configure script, period. But that's not quite good enough -- e.g. if the subproject is updated, then there is no good way for the build system to re-run its configure script. Also, AC_CONFIG_SUBDIRS insists on passing all options given to the main configure script on to the subprojects, and gives no way to add additional options to them.
So I guess to fully solve this, we would have to record all state that affects the configure output of the subproject (such as the arguments we pass it and various environment variable), and re-run it if any of those change.
Some extra complications is caused by the fact that we run make install for each subproject, installing headers into a fake prefix $builddir/extern/install/SUBPROJECTNAME/ (see #100). So we'd have to decide when to re-run make install, which seems tricky. (This might be considered another reason, besides #100, to get rid of that "make install" trick).
Right now, the configure scripts of our bundled GMP, libatomic_ops and Bohm GC are essentially only run once.
But that's not good enough. For example, if the ABI flags change (e.g. user reconfigured from 64 to 32 bit build), then obviously we need to reconfigure and rebuild the subprojects. Also if new configure flags are passed to
cnf/build-extern.shinMakefile.rules. Etc.In those cases, we likely should re-run the subproject's configure, and then do
make clean && make; or even remove the correspondingextern/build/FOO/andextern/install/FOO/directories.However, I am unsure how we'd decide when to do this -- if we do it unnecessarily, it's a nuisance for developers, if we don't do it often enough, it can lead to confusing errors, or worse.
autoconf "solves" this via
AC_CONFIG_SUBDIRS, which runs the subproject'sconfigurescript from the main project's configure script, period. But that's not quite good enough -- e.g. if the subproject is updated, then there is no good way for the build system to re-run its configure script. Also,AC_CONFIG_SUBDIRSinsists on passing all options given to the main configure script on to the subprojects, and gives no way to add additional options to them.So I guess to fully solve this, we would have to record all state that affects the configure output of the subproject (such as the arguments we pass it and various environment variable), and re-run it if any of those change.
Some extra complications is caused by the fact that we run
make installfor each subproject, installing headers into a fake prefix$builddir/extern/install/SUBPROJECTNAME/(see #100). So we'd have to decide when to re-runmake install, which seems tricky. (This might be considered another reason, besides #100, to get rid of that "make install" trick).