Hi all,
I'm not sure if I already asked this some time ago (if so, please bear with me). Compiling and linking always takes a considerable amount of time and I regularly run into the need to test the effect of several small changes in quick succession. Is there a way to speed up compiling in any way, for example by deactivating certain things which have nothing to do with the code I'm interested in? Any options for ./configure (I already use --without-inkjar), any compile switches, #ifdefs I'm not aware of, anything?
Thanks, Max
P.S.: I do use ccache but I still hope that the building (in particular, the linking) time can be reduced by other means, too.
Just answered this somewhere else, but hope this helps. Don't even know what platform you're on, but if you're not on windows, this may be transferrable if you're lucky.
On Win32 you can just delete the four files generated by btool (build.dep, config.h, inkscape_version.h and compile.lst) and the either delete or rename the inkscape directory, and then run btool again, and it will only recompile the changed modules and their deps. I don't think I would do that if I changed the devlibs in between, and I still do a clean build fairly often, but many fewer 1hr waits to test.
For more info, see http://wiki.inkscape.org/wiki/index.php/Win32Port - I've put in some more detail there.
Cheers,
Rygle
Maximilian Albert wrote:
Hi all,
I'm not sure if I already asked this some time ago (if so, please bear with me). Compiling and linking always takes a considerable amount of time and I regularly run into the need to test the effect of several small changes in quick succession. Is there a way to speed up compiling in any way, for example by deactivating certain things which have nothing to do with the code I'm interested in? Any options for ./configure (I already use --without-inkjar), any compile switches, #ifdefs I'm not aware of, anything?
Thanks, Max
P.S.: I do use ccache but I still hope that the building (in particular, the linking) time can be reduced by other means, too.
Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
True. I probably need to have some other command for "recalculate," but deleting build.dep should be enough for those times when you svn up and there is something new.
bob
(by the way, Cmake guys: can you do out-of-place compiling? :-)
rygle wrote:
Just answered this somewhere else, but hope this helps. Don't even know what platform you're on, but if you're not on windows, this may be transferrable if you're lucky.
On Win32 you can just delete the four files generated by btool (build.dep, config.h, inkscape_version.h and compile.lst) and the either delete or rename the inkscape directory, and then run btool again, and it will only recompile the changed modules and their deps. I don't think I would do that if I changed the devlibs in between, and I still do a clean build fairly often, but many fewer 1hr waits to test.
For more info, see http://wiki.inkscape.org/wiki/index.php/Win32Port - I've put in some more detail there.
On Sun, Mar 30, 2008 at 1:46 AM, Bob Jamison <rwjj@...127...> wrote:
True. I probably need to have some other command for "recalculate," but deleting build.dep should be enough for those times when you svn up and there is something new.
bob
(by the way, Cmake guys: can you do out-of-place compiling? :-)
Yes it does.
Here are some factoids I copied and pasted http://wiki.inkscape.org/wiki/index.php/CMake It's a work it progress and i will get more how to help and use stuff there later.
Joshua L. Blocher verbalshadow
Obviously compile with empty CXXFLAGS and CFLAGS (i.e. no optimization, no debugging annotations), and use ccache as you mention. These won't help link time, though.
To slightly speed up link time at cost of compile time proper, you could set CXXFLAGS and CFLAGS to -Os (just to reduce I/O). Possibly using -O/-O2 instead of -Os would speed up linking by doing more inlining during compilation, reducing the amount of symbol lookup needed during linking; I haven't tested.
I gather that the development version of binutils includes the option of using a much faster (more specialized) linker called `gold'. It's disabled by default for now; enable it by configuring with `--enable-gold'. People are reporting that it runs 5-6 times faster for sizable programs (such as inkscape), and that it seems to work correctly for linking everything but Linux. (Linux source makes heavy use of ELF features, and it even has some freedom to misuse ELF, whereas I don't think Inkscape source makes any special use of ELF or even cares what object file format is used.)
pjrm.
Peter,
I have been thinking about "gold" a lot, since a full debug link of Inkscape is now taking a huge amount of memory (>2gb?). The debug symbols alone are >256mb.
bob
Peter Moulder wrote:
Obviously compile with empty CXXFLAGS and CFLAGS (i.e. no optimization, no debugging annotations), and use ccache as you mention. These won't help link time, though.
To slightly speed up link time at cost of compile time proper, you could set CXXFLAGS and CFLAGS to -Os (just to reduce I/O). Possibly using -O/-O2 instead of -Os would speed up linking by doing more inlining during compilation, reducing the amount of symbol lookup needed during linking; I haven't tested.
I gather that the development version of binutils includes the option of using a much faster (more specialized) linker called `gold'. It's disabled by default for now; enable it by configuring with `--enable-gold'. People are reporting that it runs 5-6 times faster for sizable programs (such as inkscape), and that it seems to work correctly for linking everything but Linux. (Linux source makes heavy use of ELF features, and it even has some freedom to misuse ELF, whereas I don't think Inkscape source makes any special use of ELF or even cares what object file format is used.)
pjrm.
participants (5)
-
Bob Jamison -
Joshua Blocher -
Maximilian Albert -
Peter Moulder -
rygle