Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure subprojects are rebuilt "when necessary" #101

Open
fingolfin opened this issue Mar 21, 2017 · 0 comments
Open

Ensure subprojects are rebuilt "when necessary" #101

fingolfin opened this issue Mar 21, 2017 · 0 comments

Comments

@fingolfin
Copy link
Owner

fingolfin commented Mar 21, 2017

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant