jbb at kdevelop.org
Fri Aug 3 10:57:49 UTC 2001
On Thu, 02 Aug 2001 08:18, you wrote:
> The Linux Magazin (german) writes in its latest issue (09/2001) an article
> about a 'simple' compiler cache for C/C++. It's based on the assumption
> that source files don't have to be recompiled if there was a change in a
> comment or something comparable. Given is the following situation: There
> are 50 header files and 50 source files. Now a wrong word in the
> documentation of one header file has been corrected. Unfortunately 45
> source files depend on this one header file. Therefore all these files have
> to be recompiled although the result will be the same.
Hmm - this might be a suspect assumption when considering a debug build.
Adding new comments lines to the source (cpp or header) will make it awkward
to debug code as the line numbers have changed in source but not in the
executable - even though the executable doesn't _really_ need a compile. It
would be confusing, just like my "sliding" breakpoint bug :-).
> And another
> situation is mentioned: A project build switches often from debug code (-g)
> to optimizied code (-O2). Everytime a 'make clean' and 'make' with changed
> compiler options is needed though the compiler has compiled them in the
> past already.
This might equally be accomplished with srcdir!=buildir and allow separate
compile profiles. One profile for debug, one for profiling, one for live, one
for well, whatever you specify... Lots of disk space though.
I've not read the article - just commenting on your commentary :-) Maybe I'm
totally of track on what is proposed.
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
More information about the KDevelop-devel