<div dir="ltr">To provide some context, llvm-rc was mnbvmar's intern project, but his internship has ended. I had written a fairly functional rc reimplementation prototype at <a href="https://github.com/nico/hack/blob/master/res/rc.cc">https://github.com/nico/hack/blob/master/res/rc.cc</a> , and mnbvmar was productionizing that and adding it to llvm. From what I understand, what's currently in LLVM is fairly incomplete. Last week, for chrome, I figured it's probably better to use my thing until llvm-rc is in better shape. <a href="https://cs.chromium.org/chromium/src/build/toolchain/win/rc/README.md?sq=package:chromium&dr=C">https://cs.chromium.org/chromium/src/build/toolchain/win/rc/README.md?sq=package:chromium&dr=C</a> has an overview of that; rc.py in that file can process all .rc files in chrome's repo and produces bitwise identical output to what rc.exe produces.<div><br></div><div>If you want to use llvm-rc, you should be prepared to hack on it quite a bit. (Although, if you only want it for the VERSIONINFO resource needed to build llvm itself, then it's probably not that much work.) If you want to do that, that'd be great! My thing has a fairly good test suite that you're welcome to use; and you could look at the code too. llvm-rc definitely should support /DFOO joined.</div><div><br></div><div>In general, I think it's fine if you see llvm-rc as incomplete with no users yet and no backward compat to worry about -- so feel free to hack away at it :-)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 24, 2017 at 9:51 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@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 dir="ltr">+thakis<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 24, 2017 at 2:49 PM Shoaib Meenai <<a href="mailto:smeenai@fb.com" target="_blank">smeenai@fb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all (CC llvm-rc contributors),<br>
<br>
I've been attempting to cross-compile LLVM for Windows using clang-cl. LLVM's<br>
build system embeds resource files for MSVC builds, so I was hoping to use<br>
llvm-rc for that portion.<br>
<br>
cmake invokes the resource compiler with arguments joined to their options<br>
(e.g. `/D_WIN32`, `/fofoo.res`, etc.), which rc.exe supports, but llvm-rc<br>
expects arguments to be separate. It's simple enough to change that, of<br>
course; just change `Separate` to `JoinedOrSeparate` in the options tabledef.<br>
Unfortunately, that then causes problems with Unix-style absolute paths; for<br>
example, on macOS, `/Users/...` would be interpreted as a macro undefine<br>
rather than a path.<br>
<br>
clang-cl has similar issues, and supports such paths by treating anything<br>
after a `--` as a path. (clang-cl has it slightly easier since at least its<br>
options are case-sensitive, but it's still the same underlying issue). I'd<br>
like to make a similar change in llvm-rc (i.e., arguments can be both joined<br>
or separate, and you use `--` to resolve ambiguities between options and<br>
paths), but I wanted to run it by everyone before putting up that patch, in<br>
case it breaks people's use cases. (I doubt there are a whole lot of llvm-rc<br>
use cases right now, given that it was only introduced in the 6.0 cycle, but<br>
still.)<br>
<br>
Thanks,<br>
Shoaib<br>
<br>
</blockquote></div></div>
</blockquote></div><br></div>