[llvm] r239987 - config.h.*: Rework r210144. Don't edit config.h.in manually.

Justin Bogner via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 17 23:33:59 PDT 2015


NAKAMURA Takumi <geek4civic at gmail.com> writes:
> On Fri, Sep 18, 2015 at 8:44 AM Justin Bogner <mail at justinbogner.com> wrote:
>
>> (Re-sending to the right list)
>>
>> NAKAMURA Takumi <geek4civic at gmail.com> writes:
>> > Author: chapuni
>> > Date: Wed Jun 17 23:08:20 2015
>> > New Revision: 239987
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=239987&view=rev
>> > Log:
>> > config.h.*: Rework r210144. Don't edit config.h.in manually.
>> >
>> >   - Generate #include in configure.ac.
>> >   - Resurrect the copy of llvm-config.h.cmake into config.h.cmake.
>>
>> Sorry to bring up such an old thread, but *why* did you duplicate
>> everything from llvm-config.h.cmake into config.h.cmake? This just makes
>> it more error prone to try to update these, since they need to be
>> updated in sync. config.h #includes llvm-config.h anyway...
>>
>
> I dare to say again, "Don't edit config.h.in manually."
> As far as we maintain autoconf build, config.h.in is generated by
> configure.ac.
>
> I suppose we were working for config.h.cmake in sync to config.h.in.
> That said, config.h.cmake can easily diverge from config.h.in.
>
> And, I suppose llvm-config.h.* may be subset of config.h.*.
> I intended r239987 was "trying to keep config.h.cmake in sync to config.h.in"
> rather than "copying back from llvm-config.h.cmake into config.h.cmake".
>
> I know this is hairy.

Well, there are a few options:

1. Make config.h.cmake include llvm-config.h.cmake, and the combination
   add up to config.h.in's output. Here, we should probably check that
   we don't replace any definitions from llvm-config in config somehow.

2. Make config.h.cmake a superset of llvm-config.h.cmake, and write some
   tests to ensure that they don't get out of sync.

As is, config.h.cmake includes llvm-config.h.cmake, but if
config.h.cmake disagrees with llvm-config.h.cmake then anything that
uses the latter will be completely broken. This is unreasonable.


More information about the llvm-commits mailing list