On Jun 18, 2006, at 2:32 AM, James Crook wrote:
> I'd like to 'sort out' the precompiled headers on Audacity. It's
> 95% a
> question of deciding what we want and 5% a question of actually
> doing it.
> I've turned build timing on, and currently a clean build of Audacity
> only (libraries already built) takes 3mins 48secs. I'd like to
> reduce this.
Actually, Audacity's configure.in and src/Makefile.in already does
precompiled headers on Mac OS X, and by changing like 3 lines it
works on Linux if you're using gcc 4.0 and higher. As you noticed, I
created a file, src/AudacityHeaders.h, which contains the headers I
found most useful to precompile. (Note that both wx/wx.h and wx/
wxprec.h leave out DOZENS of wx header files that we use all over the
place, not to mention that it doesn't include any Audacity-specific
The neat part is that you don't have to add a line to all of your
header files. Just put "-include AudacityHeaders.h" on the gcc
command line and it gets inserted at the beginning of the file as if
there were a #include on line 1. Far less ugly!!!
Precompiling a header with gcc 4 or higher (3.3 or higher on Mac OS
X) is also amazingly simple:
gcc header_file.h -o headerfile.h.gch
Then, whenever gcc is told to include a file and a file with the
extension ".gch" exists, it loads the gch instead. It's that simple.
> In my own wxWidgets projects I always include <wx/wx.h> as the first
> include file, and precompile through that. All the common wx include
> files are pulled in, which is very convenient. However, for Audacity
> this approach isn't good. It would slow the builds for people not
> precompiled headers by pulling in headers they don't need.
> We in some places use:
> #include <wx/wxprec.h>
> Which is the wxWidgets solution to that problem. If you have
> precompilation wxprec.h brings in all the headers, and doesn't
> bring in
> any if you don't. Unlike including <wx/wx.h> you have to #include the
> individual wx files too, so that people not using precompilation will
> get them. As it stands it is a flawed solution. Someone using
> precompiled headers gets no warning that they have missed out a
> needed by people who are not.
> I assume that we are not, and cannot use precompilation on Linux. Is
> that right?
> If so, I'd like to conditionally #include <wx/wxprec.h> only on debug
> non-unicode builds - which is where I do nearly all my compiling.
> so often I do check a unicode build too, and that's when I'd detect a
> missing header file. How does that sound?
Use AudacityHeaders.h instead.
> At the moment sometimes we have:
> #include "Audacity.h"
> (and sometimes other files too)
> before #include <wx/wxprec.h>, and sometimes not. I think this
> the header precompilation. I'm proposing to switch over to including
> <wx/wxprec.h> at the end of Audacity.h, along with the new tests for
> debug and not unicode, and have Audacity.h be the *first* include of
> every source file in our source.
Hmmm, I'm pretty sure that precompiled headers only work if they're
at the TOP of the source file - they have to appear before any other
headers have been loaded. This is true in both gcc and in VC++ last
time I checked.
Could you check to see if VC++ has an option like gcc's "-include"
option??? That would be a lot cleaner!
By the way, the time to compile audacity/src from scratch doesn't
annoy me nearly as much as the time it takes to compile our lib-src
libraries. The worst part is that many of the libraries are building
dozens of extra libraries, test executables, and other stuff that
we're not actually using. I think that turning off some of those
would possibly be a big win in compilation speed.
> I'd also like to consider including some non-core wxWidgets headers
> like <listctrl.h> which we use in a number of places in there too.
> There is also AudacityHeaders.h which appears to be to help Mac based
> precompilation. I don't know how that fits in.
> How does this sound?
> Audacity-devel mailing list