<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Or maybe:<br>
- add a private field 'hook' in CompilationDatabase (a function
pointer to the user callback),<br>
- initialize it by default to NULL<br>
- add a setter to CompilationDatabase for this hook field<br>
- and use the hook if non null in
findCompilationDatabaseFromDirectory<br>
<br>
The burden of linking in the other required libraries is left to
the user of the hook --- which seems good to me : we can not
generally decide for the user which libraries should be linked in.<br>
<br>
This can probably be extended by changing the hook to a vector (of
hooks). This would allow registering several user backends to a
specific CompilationDatabase instance, and have it try to use them
in turn, until one succeed.<br>
<br>
Cheers,<br>
--<br>
Arnaud de Grandmaison<br>
<br>
On 07/19/2012 11:32 AM, Daniel Jasper wrote:<br>
</div>
<blockquote
cite="mid:CAK_tg0xPRBiQ31-wtg-jHPaxKzYfCUBFfDqTbSJFLKaWvCMQOA@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:chandlerc@google.com">chandlerc@google.com</a>>
wrote:<br>
>> On Wed, Jul 18, 2012 at 3:11 PM, Sean Silva
<<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Arnaud de Grandmaison
Senior CPU engineer
Business Unit Digital Tuner
Parrot S.A.
174, quai de Jemmapes
75010 Paris - France
Phone: +33 1 48 03 84 59</pre>
</body>
</html>