While I also like the plugin concept much better, I am still unsure about the fundamental problem of getting other libraries linked in. The problem is that the linker will simply throw away any object file that has no references to it. After some discussions on IRC, I see two options:<div>
<br></div><div>1. Conditionally compile in a custom registration method, i.e.:</div><div>in CompilationDatabase.cpp:</div><div> void someInit() {</div><div> #ifdef USE_CUSTOM_COMPILATION_DATABASES</div><div> RegisterCompilationDatabases();<br>
</div><div> #endif</div>
<div> }</div><div>And then implement RegisterCompilationDatabases() together with the custom compilation database.</div><div>Pros: Very easy to understand and to use right.</div><div>Cons: It would be hard to link together multiple such implementations.<br>
</div><div><br></div><div>
2. Conditionally compile in custom anchors, i.e;.:</div><div>in CompilationDatabase.cpp:</div><div> #ifdef COMPILATION_DATABASE_ANCHORS</div><div> COMPILATION_DATABASE_ANCHORS;</div><div> #endif</div><div>And then e.g. "-DCOMPILATION_DATABASE_ANCHORS='extern volatile int MyAnchorSource; static int MyAnchorDest = MyAnchorSource;'"</div>
<div>Pros: Multiple custom compilation databases can be added. Nice clean separation (conditional code can be somewhere on the bottom of "CompilationDatabase.cpp".</div><div>Cons: Seems a bit tangled and easy to get the -D part wrong.</div>
<div><br></div><div>I will try to get #2 to work (possibly simplifying it a bit with more macros :-/). Does anyone see a better solution?</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 19, 2012 at 10:42 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Jul 19, 2012 at 12:34 AM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>
>> 3) It is *incredibly* easy to write a minimal JSON writer that only supports the features we need.<br>
><br>
> Ah, ok, I seem to have overestimated how difficult/annoying this would<br>
> be to write.<br>
<br>
</div>Writing JSON is simple: it's a well-defined format with very little<br>
chance that it ever changes. No need to have a "writer", just print it<br>
out:<br>
<br>
stream << "[\n";<br>
for (tu : tus) {<br>
stream << " {\n " << "\"directory\": " << shellEscape(tu.directory())<br>
...<br>
}<br>
stream << "]\n";<br>
<br>
The hard part is the shell escaping. CMake already had that built in.<br>
<div class="HOEnZb"><div class="h5"><br>
>> We can easily place a copy of the code into LLVM or re-license it however it helps.<br>
><br>
> This might be good, to help keep things consistent. Are you thinking<br>
> something with a role like ninja's ninja_syntax.py?<br>
><br>
> --Sean Silva<br>
><br>
> On Wed, Jul 18, 2012 at 3:15 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
>> On Wed, Jul 18, 2012 at 3:11 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>
>>><br>
>>> > For ninja in particular, I have long thought that the correct approach<br>
>>> > is to write something which can convert 'ninja -t commands' into the JSON<br>
>>> > format, or to build a tool for writing the JSON database directly into<br>
>>> > ninja.<br>
>>><br>
>>> This was my line of thought as well.<br>
>>><br>
>>> Since the C++ stdlib unfortunately doesn't have JSON support, what do<br>
>>> you think about a simpler, more plaintext-y compilation database<br>
>>> (PlaintextCompilationDatabase?); it seems like that might be a win<br>
>>> since it is simpler to output. For example, the format would just be<br>
>>><br>
>>> /path/to/dir/<br>
>>> clang++ foo.cpp<br>
>>> foo.cpp<br>
>>> <empty line><br>
>>><br>
>>> Just a mirror of the JSON one, but with a format easier to output (god<br>
>>> forbid there's a newline in one of the command lines or filenames). On<br>
>>> the other hand, throwing together a simple "good-enough" JSON writer<br>
>>> isn't *too* difficult; nonetheless, for tools written in C/C++, this<br>
>>> could lower the bar to entry. Do you know what CMake currently does?<br>
>>> Does it have its own mini JSON writer?<br>
>><br>
>><br>
>> We didn't go with the plaintext route for three important reasons:<br>
>><br>
>> 1) Filenames do have whitespace in them. The format should be robust against<br>
>> that.<br>
>> 2) Many other tools and languages should have a minimal barrier to read<br>
>> them. An existing format eases this.<br>
>> 3) It is *incredibly* easy to write a minimal JSON writer that only supports<br>
>> the features we need.<br>
>><br>
>> Manuel contributed the CMake support for the JSON database, and it includes<br>
>> just such a trivial JSON writer. =] We can easily place a copy of the code<br>
>> into LLVM or re-license it however it helps.<br>
>><br>
>> That said, the latest version of CMake already has support for JSON + Ninja<br>
>> -- we didn't contribute it, so I don't know what strategy they followed, but<br>
>> you should look at that and talk to the ninja and CMake developers before<br>
>> going too far here.<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div>