llvm-rc option parsing

Hi all (CC llvm-rc contributors),

I've been attempting to cross-compile LLVM for Windows using clang-cl. LLVM's
build system embeds resource files for MSVC builds, so I was hoping to use
llvm-rc for that portion.

cmake invokes the resource compiler with arguments joined to their options
(e.g. `/D_WIN32`, `/fofoo.res`, etc.), which rc.exe supports, but llvm-rc
expects arguments to be separate. It's simple enough to change that, of
course; just change `Separate` to `JoinedOrSeparate` in the options tabledef.
Unfortunately, that then causes problems with Unix-style absolute paths; for
example, on macOS, `/Users/...` would be interpreted as a macro undefine
rather than a path.

clang-cl has similar issues, and supports such paths by treating anything
after a `--` as a path. (clang-cl has it slightly easier since at least its
options are case-sensitive, but it's still the same underlying issue). I'd
like to make a similar change in llvm-rc (i.e., arguments can be both joined
or separate, and you use `--` to resolve ambiguities between options and
paths), but I wanted to run it by everyone before putting up that patch, in
case it breaks people's use cases. (I doubt there are a whole lot of llvm-rc
use cases right now, given that it was only introduced in the 6.0 cycle, but



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 https://github.com/nico/hack/blob/master/res/rc.cc , 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. https://cs.chromium.org/chromium/src/build/toolchain/win/rc/README.md?sq=package:chromium&dr=C 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.

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.

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 :slight_smile: