[llvm-commits] [PATCH] Splitting PACKAGE_VERSION and friends out of config.h

Frits van Bommel fvbommel at gmail.com
Sat Nov 20 06:42:03 PST 2010


A while back I noticed that whenever CMake reconfigured the LLVM tree,
a lot of objects that didn't #include any changed files were being
recompiled. I did some investigating, and it turned out this was
because reconfiguring caused llvm/Config/config.h to change because
this is when the svn revision number is queried and inserted into the
PACKAGE_VERSION and PACKAGE_STRING by CMake. This caused quite a few
files to be recompiled because they (directly or indirectly) #included
config.h.
Most of those files didn't use those particular macros, and it turned
out the ones that did didn't use the rest of config.h other than
PACKAGE_NAME (which isn't used together with any other macros from
config.h either).

So I created the attached patches which move those three macros
(PACKAGE_NAME, PACKAGE_STRING and PACKAGE_VERSION) to
llvm/Config/version.h instead and update llvm and clang sources to
match. I've had these changes in my local tree for a couple of days
now and haven't noticed any problems, so I'm pretty sure the CMake
part of it is correct. The number of files rebuilt when CMake
reconfigures has definitely gone down and version numbers are still
updated (*only* when CMake reconfigures, but that was a pre-existing
bug I'm not sure how to fix yet).

Now I have some questions:
1) Could someone verify that the CMake version builds when applied to
a "clean" tree just to make sure I didn't forget to include any
changes or depend on any files I left behind while experimenting with
this?
2) Before this is committed the autoconf build should work too so I
also made some changes related to that. However I'm completely
unfamiliar with how autoconf works, so I'm less sure whether those are
correct. Could someone check those for me? (And if something's wrong
tell me how to fix it? :) )
2a) By the way, am I correct in concluding that the autoconf build
doesn't add vcs revision numbers to the PACKAGE_VERSION and
PACKAGE_STRING macros?
3) Are there any other LLVM subprojects using those macros that need
to be adjusted? (I grepped the llvm-gcc and dragonegg trees but they
don't seem to use them)
4) Does this seem like a good idea to anyone? :)


P.S. there are also some minor changes in the patches:
a) I re-alphabetized some of the #include lists of files that now
#include version.h.
b) autoconf/configure.ac referenced the variable FilesToConfig in
Makefile.rules, but it turned out to be in Makefile instead, so I
updated the comment.
c) version.h was added to the svn:ignore property for
include/llvm/Config. (If someone other than me ends up committing
this[1], pay particular attention to this one since 'patch -p0 <
svnversion-llvm.patch' won't update it)


[1]: I've requested commit access but Chris hasn't gotten back to me yet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svnversion-llvm.patch
Type: text/x-patch
Size: 6041 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101120/287c912e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svnversion-clang.patch
Type: text/x-patch
Size: 1366 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101120/287c912e/attachment-0001.bin>


More information about the llvm-commits mailing list