> One of the bugs I was fixing was in an inline function, defined in the header. The bug fix was tiny - changed one line of code. Perfect for a patch release. Unfortunately, a number of other packages used this inline function. And so they had to be rebuilt as well.
The problem is much deeper. There is not really any separation between interface and implementation in C++. You are obliged to expose parts of your implementation (things which should be hidden) in header files, which are seen by everyone else. One consequence is that you should recompile everything even when interface doesn’t change (as in your case). Another consequence is very long compilation time; compiler compiles in fact much bigger files than you implementation - it includes headers from many other classes.
> Ironically, however, at least in ATLAS, the compile step is fast — everything that has to be done to get to the compile step, however, is very slow (the build system).
The compile step is fast in comparison with other steps. However, the compile step in Atlas/C++ is incredibly slow if you compare it with some other languages. I have Java projects, where I compile several hundred classes in several seconds.
In fact, slowness of other steps comes probably mostly from the same source. Your end-user class may be very simple, but it depends on just everything else via repetitive include files. So the system has too get them first even before it starts doing anything serious. And when you are on AFS, it is already the amount of data you have to read (i.e. to move to your machine) which kills you. The same when you try to create libraries, build dictionaries,…
Even when your project may look very modular, it is not modular at the system level.
(from the dicsussion on the blog of Gordon Watts)
No comments:
Post a Comment