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 :-)
On Tue, Oct 24, 2017 at 9:51 PM, Zachary Turner <zturner at google.com>
wrote:
> +thakis
>
> On Tue, Oct 24, 2017 at 2:49 PM Shoaib Meenai <smeenai at fb.com>
wrote:
>
>> 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
>> still.)
>>
>> Thanks,
>> Shoaib
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171024/ff662ba9/attachment.html>