<div dir="ltr"><div dir="ltr">Hi Doug,</div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="text-align:left;direction:ltr"><div>I'm pretty new to the LLVM project so I'm not sure how best to proceed.<br></div></div></blockquote><div>Welcome! Happy to have you on board! </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="text-align:left;direction:ltr"><div></div>
<div>We are working on using clangd in the Eclipse CDT context (which is now also building VS Code extensions) where we mainly support developers building embedded systems. Most of these systems use gcc as the compiler and where clang does not have target support.<br></div>
<div>I've been able to get clangd to properly deal with these projects by forking llmv and clang and adding Triples and Toolchains to properly set up the system include paths and built-in macros and other properties clang needs to parse.<br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="text-align:left;direction:ltr"><div>I also have a hack in the clangd layer to figure out the '-target' argument from the gcc command and inject it when fetching from the compilation database. This part is especially ugly and I'm hoping to find a better way.<br></div></div></blockquote><div>How do you figure it out currently? If the fork is public, could you provide the pointers to the code? My initial intuition is that it would make sense for this to live somewhere in the Tooling library (which defines abstractions for compile_commands.json), would also enable things like clang-tidy for those use-cases.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="text-align:left;direction:ltr"><div></div>
<div>The main question I have: is there appetite for changes like this to be pushed upstream, even though these targets are not meant to be used by clang itself? Or is a fork the proper way to deal with this? Is there anyone else doing something similar?<br></div></div></blockquote><div><a class="gmail_plusreply" id="gmail-plusReplyChip-1" href="mailto:cfe-dev@lists.llvm.org" tabindex="-1">+via cfe-dev</a> for figuring out whether it's fine to have targets supported only in the frontend without the prospect of them being implemented in the backend.</div><div>From the clangd's standpoint (and more generally, from other source-level tools like clang-tidy, etc.) this would make total sense: if clang can run for some targets only with `-fsyntax-only` (producing an error in the modes that need the codegen), all the source-level tools can still be used there.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="text-align:left;direction:ltr"><div></div>
<div><br>
</div>
<div>Thanks!</div>
<div>Doug.</div>
</div>

_______________________________________________<br>
clangd-dev mailing list<br>
<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div><div>Ilya Biryukov</div></div></div></div></div></div>