Bryce Harrington wrote:
Actually, I believe we did make adjustments to the build system at that time (still using autoconf/make, but in a slightly tweaked way.) I think we also noticed that changing the build system did not solve the underlying problem that had prompted the discussion in the first place.
One of the main problems that precipitated the earlier discussions about other build systems was that we notice that seemingly minor changes can prevoke entire-codebase rebuilds. This is because of rampant header inclusion. One of the changes we're experimenting with in the new gtkmm codebase is 'implementation hiding'. This is a technique where a main header is kept extremely terse using forward declarations of classes instead of having to include the respective header, and by moving private details of a global class out into an 'Impl' object (see the Inkscape::Application class in inkscape_gtkmm for an example). Another example is the Dialog::Manager class, that lets you invoke and show dialogs without needing to know anything about the implementation of the given dialog.
I believe techniques like these will help us slice through the header inclusion problem. If we do indeed notice the benefits of this approach for the UI code, I hope we can replicate the approach through other areas of the code and eventually solve the compilation issues for real.
Bryce
I would like to amplify that, going so far as saying that any major API item should be separated into interfaces and implementations; the interfaces being pure virtual with -NO- link dependencies. This is help in:
o Reducing compile times o Alleviating cascading link dependencies o Scripting (binding a scripted object to an interface) o Allow clean exporting of an Inkscape API.
Bob