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

[Óscar Fuentes]

Frits van Bommel <fvbommel at gmail.com>
writes:

> 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.

Right. I was thinking on removing that feature altogether. It was
implemented on LLVM because clang already had it, but has two serious
drawbacks:

 1. As you say, too often causes a massive recompilation.

 2. It is unreliable, on the sense that the reported svn/git revision id
    is not necessarily the current one on the working copy, as it is
    only updated when cmake runs, and that doesn't happen unless some
    CMakeLists.txt file changed (or you explicitly invoke cmake).

So I'm inclined to removing the feature, or making it optional
defaulting to OFF. In that case we could solve problem #2 by calculating
the revision id at build time, instead of config time.

> 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

IIRC it is an standard practice to put those macros in config.h.

[snip]

> 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? :) )

This is very important. I don't want to introduce unnecessary
differences between config.h.in and config.h.cmake.

[snip]