I keep seeing people talking about moving towards single-header includes with GTK+. I’m not sure why this is suddenly a big deal without much discussion about whether it’s actually a good thing, but I do want to bring up one concern.
<gtk.h> includes a heck of a lot of other files.
Here’s a test, building the VMware Workstation UI with and without single-header includes (on my 8-core beast):
Status quo: real 4m34.861s user 17m46.059s sys 1m44.091s Single-header include: real 5m16.210s user 19m56.175s sys 1m55.627s
The actual percentage time per file is quite a bit higher than this shows; I’m estimating that at least 60% of the “real” time is spent doing mtime checks and dependency analysis in our build system.
Perhaps there’s a good reason for single-header includes, and it just hasn’t been communicated. Meanwhile, this does have a noticible impact for developers on large codebases.
On the other hand, maybe we can precompile gtk.h and everything that comes from that?
#1 by Xavier Claessens on December 8th, 2008
Quote
IIRC, by forcing single include, moving a function from one file to another doesn’t break API. That makes easier to move all deprecated symbols in one place, things like that…
IMHO, build time doesn’t matter at all.
#2 by Kalle Vahlman on December 8th, 2008
Quote
It has been communicated:
http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00144.html
Whether or not you want to trade your 40 secods per build to GTK+ developers X amount of hours of maintenance work (due to the inclusion mess) is another thing of course…
#3 by Mathias Hasselmann on December 8th, 2008
Quote
Reason for that change what, that allowing inclusion of specific headers dramatically increases the API promised to be stable without much gain:
- you cannot move axillary declarations arround if it turns out that they represent a generic concept
– you cannot remove obsolete or accidential include directives
To summarize it: Allowing inclusion of specific header files increases bit rot. So deprecating this feature is an action of code hygiene.
I don’t think that the increased build time is that much an issue: During development you only do incremental builds most of the time.
I also wonder if the “large” number of CPUs in your system causes this increased build time. I could imagine that the CPUs block each other when waiting for your harddisk to deliver include files.
Regarding precompiled headers: You might want to try ccache.
#4 by David Trowbridge on December 8th, 2008
Quote
Build time is of course an issue–it involves the quality of life for developers. The faster my turnaround time, the more efficiently I work. If I have to wait too long, I flip over to email, IM, or my web browser, and my productivity is shot.
“Moving auxiliary definitions around” seems to me to be a meaningless point. You’ve probably already given these definitions names which associate them with a given file.
As far as “remove obsolete or accidental include directives” goes, I don’t have a lot of sympathy for application developers who use direct includes sloppily.
The number of CPUs doesn’t add much overhead here; I’m doing a bunch of parallel compiles, and so almost all of my wait time is I/O. Last time I checked, the Linux I/O scheduler scaled linearly with CPUs.
ccache won’t help because it only takes effect *after* the preprocessing stage.
I understand that this does have some maintenance impact. The email that Kalle linked helps explain it better; it would have been nice if this reasoning was communicated along with the rest of the GTK+ plans, instead of in a mail entitled “GIO API review.”
In any case, I certainly hope 2 things:
1. Nobody considers flipping the switch before 3.0
2. People do take a look at things like precompiled headers, and even if they’re not something that can be done along with the library, publish some docs to help application authors out.
I also realize this is only an issue for the largest applications out there (things like VMware Workstation, OOo and others). Given the way things tend to work, that probably means it won’t be given a second thought.
#5 by Chris S. on December 8th, 2008
Quote
If you have a large enough build, won’t you be including most of the headers anyway?
#6 by David Trowbridge on December 8th, 2008
Quote
A lot of the GTK headers do get included if you’re talking about the project as a whole. However, each individual file includes between 0 and 30 headers (biased towards 3–5). That’s a lot less I/O per file than the ~200 that you get from
#7 by Christian on December 8th, 2008
Quote
So if IO is your concern, feel free to file a bug about a precompiled header.That shouldn’t be hard to generate automatically with a script. That script could easily be shipped with or part of the build system.
#8 by Lieven on December 8th, 2008
Quote
@Chris S.
Definitely not! In my experience, the only real way to get fast compile times is to be really aggressive with forward declaration, and only include the absolute minimum in your header files (often just the base class types, and the types of non ptr members variables. If you do this consistently, most C++ files will really only include the stuff they absolutely need.
This of course makes your normal builds a lot faster, but the real big gain is that the set of files that needs to be recompiled when you change something becomes a LOT smaller (and thus faster).