2017-08-10 16:21:44 +00:00
|
|
|
//===-- llvm-rc.cpp - Compile .rc scripts into .res -------------*- C++ -*-===//
|
2017-07-25 00:25:18 +00:00
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2017-07-25 00:25:18 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// Compile .rc scripts into .res files. This is intended to be a
|
|
|
|
// platform-independent port of Microsoft's rc.exe tool.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-09-29 17:14:09 +00:00
|
|
|
#include "ResourceFileWriter.h"
|
2018-05-09 18:21:03 +00:00
|
|
|
#include "ResourceScriptCppFilter.h"
|
2017-08-18 18:24:17 +00:00
|
|
|
#include "ResourceScriptParser.h"
|
2017-09-29 17:14:09 +00:00
|
|
|
#include "ResourceScriptStmt.h"
|
|
|
|
#include "ResourceScriptToken.h"
|
2017-08-10 16:21:44 +00:00
|
|
|
|
2023-03-24 00:37:29 +02:00
|
|
|
#include "llvm/Config/llvm-config.h"
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
#include "llvm/Object/WindowsResource.h"
|
2017-07-25 00:25:18 +00:00
|
|
|
#include "llvm/Option/Arg.h"
|
|
|
|
#include "llvm/Option/ArgList.h"
|
2023-08-04 11:19:09 -07:00
|
|
|
#include "llvm/Option/OptTable.h"
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2017-07-25 00:25:18 +00:00
|
|
|
#include "llvm/Support/Error.h"
|
2017-09-29 17:14:09 +00:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2021-04-14 16:24:30 +03:00
|
|
|
#include "llvm/Support/FileUtilities.h"
|
2023-02-10 19:40:56 +00:00
|
|
|
#include "llvm/Support/LLVMDriver.h"
|
2017-11-17 01:00:35 +00:00
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
2018-05-02 21:15:24 +00:00
|
|
|
#include "llvm/Support/Path.h"
|
2017-07-25 00:25:18 +00:00
|
|
|
#include "llvm/Support/PrettyStackTrace.h"
|
|
|
|
#include "llvm/Support/Process.h"
|
2021-04-14 16:24:30 +03:00
|
|
|
#include "llvm/Support/Program.h"
|
2017-07-25 00:25:18 +00:00
|
|
|
#include "llvm/Support/Signals.h"
|
2021-04-14 16:24:30 +03:00
|
|
|
#include "llvm/Support/StringSaver.h"
|
2017-07-25 00:25:18 +00:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2023-02-10 09:59:46 +00:00
|
|
|
#include "llvm/TargetParser/Host.h"
|
2023-02-07 12:21:51 +00:00
|
|
|
#include "llvm/TargetParser/Triple.h"
|
2017-07-25 00:25:18 +00:00
|
|
|
|
2019-01-16 08:09:22 +00:00
|
|
|
#include <algorithm>
|
2017-07-25 00:25:18 +00:00
|
|
|
#include <system_error>
|
|
|
|
|
|
|
|
using namespace llvm;
|
2017-09-29 17:14:09 +00:00
|
|
|
using namespace llvm::rc;
|
Reapply "[Option] Add "Visibility" field and clone the OptTable APIs to use it"
This reverts commit 4e3b89483a6922d3f48670bb1c50a37f342918c6, with
fixes for places I'd missed updating in lld and lldb. I've also
renamed OptionVisibility::Default to "DefaultVis" to avoid ambiguity
since the undecorated name has to be available anywhere Options.inc is
included.
Original message follows:
This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
2023-08-14 14:07:04 -07:00
|
|
|
using namespace llvm::opt;
|
2017-07-25 00:25:18 +00:00
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
// Input options tables.
|
|
|
|
|
|
|
|
enum ID {
|
|
|
|
OPT_INVALID = 0, // This is not a correct option ID.
|
2023-08-04 11:19:09 -07:00
|
|
|
#define OPTION(...) LLVM_MAKE_OPT_ID(__VA_ARGS__),
|
2017-07-25 00:25:18 +00:00
|
|
|
#include "Opts.inc"
|
|
|
|
#undef OPTION
|
|
|
|
};
|
|
|
|
|
2022-12-26 09:19:09 +01:00
|
|
|
namespace rc_opt {
|
|
|
|
#define PREFIX(NAME, VALUE) \
|
|
|
|
static constexpr StringLiteral NAME##_init[] = VALUE; \
|
|
|
|
static constexpr ArrayRef<StringLiteral> NAME(NAME##_init, \
|
|
|
|
std::size(NAME##_init) - 1);
|
2017-07-25 00:25:18 +00:00
|
|
|
#include "Opts.inc"
|
|
|
|
#undef PREFIX
|
|
|
|
|
2022-12-23 13:25:58 +01:00
|
|
|
static constexpr opt::OptTable::Info InfoTable[] = {
|
2023-08-04 11:19:09 -07:00
|
|
|
#define OPTION(...) LLVM_CONSTRUCT_OPT_INFO(__VA_ARGS__),
|
2017-07-25 00:25:18 +00:00
|
|
|
#include "Opts.inc"
|
|
|
|
#undef OPTION
|
|
|
|
};
|
2022-12-26 09:19:09 +01:00
|
|
|
} // namespace rc_opt
|
2017-07-25 00:25:18 +00:00
|
|
|
|
2022-12-30 08:32:59 +01:00
|
|
|
class RcOptTable : public opt::GenericOptTable {
|
2017-07-25 00:25:18 +00:00
|
|
|
public:
|
2022-12-30 08:32:59 +01:00
|
|
|
RcOptTable() : GenericOptTable(rc_opt::InfoTable, /* IgnoreCase = */ true) {}
|
2017-07-25 00:25:18 +00:00
|
|
|
};
|
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
enum Windres_ID {
|
|
|
|
WINDRES_INVALID = 0, // This is not a correct option ID.
|
2023-08-04 11:19:09 -07:00
|
|
|
#define OPTION(...) LLVM_MAKE_OPT_ID_WITH_ID_PREFIX(WINDRES_, __VA_ARGS__),
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
#include "WindresOpts.inc"
|
|
|
|
#undef OPTION
|
|
|
|
};
|
|
|
|
|
2022-12-26 09:19:09 +01:00
|
|
|
namespace windres_opt {
|
|
|
|
#define PREFIX(NAME, VALUE) \
|
|
|
|
static constexpr StringLiteral NAME##_init[] = VALUE; \
|
|
|
|
static constexpr ArrayRef<StringLiteral> NAME(NAME##_init, \
|
|
|
|
std::size(NAME##_init) - 1);
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
#include "WindresOpts.inc"
|
|
|
|
#undef PREFIX
|
|
|
|
|
2022-12-26 09:19:09 +01:00
|
|
|
static constexpr opt::OptTable::Info InfoTable[] = {
|
2023-08-04 11:19:09 -07:00
|
|
|
#define OPTION(...) \
|
|
|
|
LLVM_CONSTRUCT_OPT_INFO_WITH_ID_PREFIX(WINDRES_, __VA_ARGS__),
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
#include "WindresOpts.inc"
|
|
|
|
#undef OPTION
|
|
|
|
};
|
2022-12-26 09:19:09 +01:00
|
|
|
} // namespace windres_opt
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
|
2022-12-30 08:32:59 +01:00
|
|
|
class WindresOptTable : public opt::GenericOptTable {
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
public:
|
2022-12-26 09:19:09 +01:00
|
|
|
WindresOptTable()
|
2022-12-30 08:32:59 +01:00
|
|
|
: GenericOptTable(windres_opt::InfoTable, /* IgnoreCase = */ false) {}
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
};
|
|
|
|
|
2017-07-25 00:25:18 +00:00
|
|
|
static ExitOnError ExitOnErr;
|
2021-04-14 16:24:30 +03:00
|
|
|
static FileRemover TempPreprocFile;
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
static FileRemover TempResFile;
|
2017-08-10 16:21:44 +00:00
|
|
|
|
2021-07-28 09:31:14 -07:00
|
|
|
[[noreturn]] static void fatalError(const Twine &Message) {
|
2017-08-10 16:21:44 +00:00
|
|
|
errs() << Message << "\n";
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2021-04-14 16:24:30 +03:00
|
|
|
std::string createTempFile(const Twine &Prefix, StringRef Suffix) {
|
|
|
|
std::error_code EC;
|
|
|
|
SmallString<128> FileName;
|
|
|
|
if ((EC = sys::fs::createTemporaryFile(Prefix, Suffix, FileName)))
|
|
|
|
fatalError("Unable to create temp file: " + EC.message());
|
|
|
|
return static_cast<std::string>(FileName);
|
|
|
|
}
|
|
|
|
|
2022-02-08 09:26:09 +01:00
|
|
|
ErrorOr<std::string> findClang(const char *Argv0, StringRef Triple) {
|
2023-08-07 00:17:01 +03:00
|
|
|
// This just needs to be some symbol in the binary.
|
|
|
|
void *P = (void*) (intptr_t) findClang;
|
|
|
|
std::string MainExecPath = llvm::sys::fs::getMainExecutable(Argv0, P);
|
|
|
|
if (MainExecPath.empty())
|
|
|
|
MainExecPath = Argv0;
|
|
|
|
|
2021-04-14 16:24:30 +03:00
|
|
|
ErrorOr<std::string> Path = std::error_code();
|
2022-02-08 09:26:09 +01:00
|
|
|
std::string TargetClang = (Triple + "-clang").str();
|
2023-03-24 00:37:29 +02:00
|
|
|
std::string VersionedClang = ("clang-" + Twine(LLVM_VERSION_MAJOR)).str();
|
2023-08-25 15:12:56 -07:00
|
|
|
for (const auto *Name :
|
|
|
|
{TargetClang.c_str(), VersionedClang.c_str(), "clang", "clang-cl"}) {
|
|
|
|
for (const StringRef Parent :
|
|
|
|
{llvm::sys::path::parent_path(MainExecPath),
|
|
|
|
llvm::sys::path::parent_path(Argv0)}) {
|
|
|
|
// Look for various versions of "clang" first in the MainExecPath parent
|
|
|
|
// directory and then in the argv[0] parent directory.
|
|
|
|
// On Windows (but not Unix) argv[0] is overwritten with the eqiuvalent
|
|
|
|
// of MainExecPath by InitLLVM.
|
2021-04-14 16:24:30 +03:00
|
|
|
Path = sys::findProgramByName(Name, Parent);
|
|
|
|
if (Path)
|
|
|
|
return Path;
|
|
|
|
}
|
|
|
|
}
|
2023-08-25 15:12:56 -07:00
|
|
|
|
2021-04-14 16:24:30 +03:00
|
|
|
// If no parent directory known, or not found there, look everywhere in PATH
|
|
|
|
for (const auto *Name : {"clang", "clang-cl"}) {
|
|
|
|
Path = sys::findProgramByName(Name);
|
|
|
|
if (Path)
|
|
|
|
return Path;
|
|
|
|
}
|
|
|
|
return Path;
|
|
|
|
}
|
|
|
|
|
2021-06-18 22:59:58 +03:00
|
|
|
bool isUsableArch(Triple::ArchType Arch) {
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
switch (Arch) {
|
2021-04-21 12:40:39 +03:00
|
|
|
case Triple::x86:
|
|
|
|
case Triple::x86_64:
|
|
|
|
case Triple::arm:
|
|
|
|
case Triple::thumb:
|
|
|
|
case Triple::aarch64:
|
|
|
|
// These work properly with the clang driver, setting the expected
|
|
|
|
// defines such as _WIN32 etc.
|
2021-06-18 22:59:58 +03:00
|
|
|
return true;
|
2021-04-21 12:40:39 +03:00
|
|
|
default:
|
|
|
|
// Other archs aren't set up for use with windows as target OS, (clang
|
2021-06-18 22:59:58 +03:00
|
|
|
// doesn't define e.g. _WIN32 etc), so with them we need to set a
|
|
|
|
// different default arch.
|
|
|
|
return false;
|
2021-04-21 12:40:39 +03:00
|
|
|
}
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
}
|
|
|
|
|
2021-06-18 22:59:58 +03:00
|
|
|
Triple::ArchType getDefaultFallbackArch() {
|
|
|
|
return Triple::x86_64;
|
|
|
|
}
|
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
std::string getClangClTriple() {
|
|
|
|
Triple T(sys::getDefaultTargetTriple());
|
2021-06-18 22:59:58 +03:00
|
|
|
if (!isUsableArch(T.getArch()))
|
|
|
|
T.setArch(getDefaultFallbackArch());
|
2021-04-21 12:40:39 +03:00
|
|
|
T.setOS(Triple::Win32);
|
|
|
|
T.setVendor(Triple::PC);
|
|
|
|
T.setEnvironment(Triple::MSVC);
|
|
|
|
T.setObjectFormat(Triple::COFF);
|
2021-04-14 16:24:30 +03:00
|
|
|
return T.str();
|
|
|
|
}
|
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
std::string getMingwTriple() {
|
|
|
|
Triple T(sys::getDefaultTargetTriple());
|
2021-06-18 22:59:58 +03:00
|
|
|
if (!isUsableArch(T.getArch()))
|
|
|
|
T.setArch(getDefaultFallbackArch());
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
if (T.isWindowsGNUEnvironment())
|
|
|
|
return T.str();
|
|
|
|
// Write out the literal form of the vendor/env here, instead of
|
|
|
|
// constructing them with enum values (which end up with them in
|
|
|
|
// normalized form). The literal form of the triple can matter for
|
|
|
|
// finding include files.
|
|
|
|
return (Twine(T.getArchName()) + "-w64-mingw32").str();
|
|
|
|
}
|
|
|
|
|
|
|
|
enum Format { Rc, Res, Coff, Unknown };
|
|
|
|
|
|
|
|
struct RcOptions {
|
|
|
|
bool Preprocess = true;
|
|
|
|
bool PrintCmdAndExit = false;
|
|
|
|
std::string Triple;
|
[llvm-windres] Change the interpretation of --preprocessor to match Binutils 2.36 (#75391)
Binutils 2.36 had a somewhat controversial change in how the
--preprocessor option was handled in GNU windres; previously, the option
was interpreted as a part of the command string, potentially containing
multiple arguments (which even was hinted at in the documentation).
In Binutils 2.36, this was changed to interpret the --preprocessor
argument as one argument (possibly containing spaces) pointing at the
preprocessor executable.
The existing behaviour where implicit arguments like -E -xc -DRC_INVOKED
are dropped if --preprocessor is specified, was kept.
This was a breaking change for some users of GNU windres, see
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594, and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f.
As multiple years have passed since, the behaviour change seems to be
here to stay, and any users of the previous form of the option have been
forced to avoid this construct. Thus update llvm-windres to match the
new way Binutils of handling this option.
One construct for specifying the path to the preprocessor, which works
both before and after binutils 2.36 (and this change in llvm-windres) is
to specify options like this:
--preprocessor path/to/executable --preprocessor-arg -E
--preprocessor-arg -xc -DRC_INVOKED
2023-12-18 12:31:05 +02:00
|
|
|
std::optional<std::string> Preprocessor;
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
std::vector<std::string> PreprocessArgs;
|
|
|
|
|
|
|
|
std::string InputFile;
|
|
|
|
Format InputFormat = Rc;
|
|
|
|
std::string OutputFile;
|
|
|
|
Format OutputFormat = Res;
|
|
|
|
|
2023-03-24 00:24:23 +02:00
|
|
|
bool IsWindres = false;
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
bool BeVerbose = false;
|
|
|
|
WriterParams Params;
|
|
|
|
bool AppendNull = false;
|
|
|
|
bool IsDryRun = false;
|
|
|
|
// Set the default language; choose en-US arbitrarily.
|
|
|
|
unsigned LangId = (/*PrimaryLangId*/ 0x09) | (/*SubLangId*/ 0x01 << 10);
|
|
|
|
};
|
|
|
|
|
2023-03-24 12:06:24 +02:00
|
|
|
void preprocess(StringRef Src, StringRef Dst, const RcOptions &Opts,
|
2021-04-14 16:24:30 +03:00
|
|
|
const char *Argv0) {
|
|
|
|
std::string Clang;
|
[llvm-windres] Change the interpretation of --preprocessor to match Binutils 2.36 (#75391)
Binutils 2.36 had a somewhat controversial change in how the
--preprocessor option was handled in GNU windres; previously, the option
was interpreted as a part of the command string, potentially containing
multiple arguments (which even was hinted at in the documentation).
In Binutils 2.36, this was changed to interpret the --preprocessor
argument as one argument (possibly containing spaces) pointing at the
preprocessor executable.
The existing behaviour where implicit arguments like -E -xc -DRC_INVOKED
are dropped if --preprocessor is specified, was kept.
This was a breaking change for some users of GNU windres, see
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594, and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f.
As multiple years have passed since, the behaviour change seems to be
here to stay, and any users of the previous form of the option have been
forced to avoid this construct. Thus update llvm-windres to match the
new way Binutils of handling this option.
One construct for specifying the path to the preprocessor, which works
both before and after binutils 2.36 (and this change in llvm-windres) is
to specify options like this:
--preprocessor path/to/executable --preprocessor-arg -E
--preprocessor-arg -xc -DRC_INVOKED
2023-12-18 12:31:05 +02:00
|
|
|
if (Opts.PrintCmdAndExit || Opts.Preprocessor) {
|
2021-04-14 16:24:30 +03:00
|
|
|
Clang = "clang";
|
|
|
|
} else {
|
2022-02-08 09:26:09 +01:00
|
|
|
ErrorOr<std::string> ClangOrErr = findClang(Argv0, Opts.Triple);
|
2021-04-14 16:24:30 +03:00
|
|
|
if (ClangOrErr) {
|
|
|
|
Clang = *ClangOrErr;
|
|
|
|
} else {
|
2023-03-24 12:06:24 +02:00
|
|
|
errs() << "llvm-rc: Unable to find clang for preprocessing."
|
2021-04-14 16:24:30 +03:00
|
|
|
<< "\n";
|
2023-03-24 00:24:23 +02:00
|
|
|
StringRef OptionName =
|
|
|
|
Opts.IsWindres ? "--no-preprocess" : "-no-preprocess";
|
2023-03-24 12:06:24 +02:00
|
|
|
errs() << "Pass " << OptionName << " to disable preprocessing.\n";
|
|
|
|
fatalError("llvm-rc: Unable to preprocess.");
|
2021-04-14 16:24:30 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
SmallVector<StringRef, 8> Args = {
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
Clang, "--driver-mode=gcc", "-target", Opts.Triple, "-E",
|
|
|
|
"-xc", "-DRC_INVOKED"};
|
2023-12-15 20:16:19 +02:00
|
|
|
std::string PreprocessorExecutable;
|
[llvm-windres] Change the interpretation of --preprocessor to match Binutils 2.36 (#75391)
Binutils 2.36 had a somewhat controversial change in how the
--preprocessor option was handled in GNU windres; previously, the option
was interpreted as a part of the command string, potentially containing
multiple arguments (which even was hinted at in the documentation).
In Binutils 2.36, this was changed to interpret the --preprocessor
argument as one argument (possibly containing spaces) pointing at the
preprocessor executable.
The existing behaviour where implicit arguments like -E -xc -DRC_INVOKED
are dropped if --preprocessor is specified, was kept.
This was a breaking change for some users of GNU windres, see
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594, and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f.
As multiple years have passed since, the behaviour change seems to be
here to stay, and any users of the previous form of the option have been
forced to avoid this construct. Thus update llvm-windres to match the
new way Binutils of handling this option.
One construct for specifying the path to the preprocessor, which works
both before and after binutils 2.36 (and this change in llvm-windres) is
to specify options like this:
--preprocessor path/to/executable --preprocessor-arg -E
--preprocessor-arg -xc -DRC_INVOKED
2023-12-18 12:31:05 +02:00
|
|
|
if (Opts.Preprocessor) {
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
Args.clear();
|
[llvm-windres] Change the interpretation of --preprocessor to match Binutils 2.36 (#75391)
Binutils 2.36 had a somewhat controversial change in how the
--preprocessor option was handled in GNU windres; previously, the option
was interpreted as a part of the command string, potentially containing
multiple arguments (which even was hinted at in the documentation).
In Binutils 2.36, this was changed to interpret the --preprocessor
argument as one argument (possibly containing spaces) pointing at the
preprocessor executable.
The existing behaviour where implicit arguments like -E -xc -DRC_INVOKED
are dropped if --preprocessor is specified, was kept.
This was a breaking change for some users of GNU windres, see
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594, and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f.
As multiple years have passed since, the behaviour change seems to be
here to stay, and any users of the previous form of the option have been
forced to avoid this construct. Thus update llvm-windres to match the
new way Binutils of handling this option.
One construct for specifying the path to the preprocessor, which works
both before and after binutils 2.36 (and this change in llvm-windres) is
to specify options like this:
--preprocessor path/to/executable --preprocessor-arg -E
--preprocessor-arg -xc -DRC_INVOKED
2023-12-18 12:31:05 +02:00
|
|
|
Args.push_back(*Opts.Preprocessor);
|
2023-12-15 20:16:19 +02:00
|
|
|
if (!sys::fs::can_execute(Args[0])) {
|
|
|
|
if (auto P = sys::findProgramByName(Args[0])) {
|
|
|
|
PreprocessorExecutable = *P;
|
|
|
|
Args[0] = PreprocessorExecutable;
|
|
|
|
}
|
|
|
|
}
|
2021-04-14 16:24:30 +03:00
|
|
|
}
|
2023-12-15 20:15:07 +02:00
|
|
|
for (const auto &S : Opts.PreprocessArgs)
|
|
|
|
Args.push_back(S);
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
Args.push_back(Src);
|
|
|
|
Args.push_back("-o");
|
|
|
|
Args.push_back(Dst);
|
|
|
|
if (Opts.PrintCmdAndExit || Opts.BeVerbose) {
|
2021-04-14 16:24:30 +03:00
|
|
|
for (const auto &A : Args) {
|
|
|
|
outs() << " ";
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
sys::printArg(outs(), A, Opts.PrintCmdAndExit);
|
2021-04-14 16:24:30 +03:00
|
|
|
}
|
|
|
|
outs() << "\n";
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
if (Opts.PrintCmdAndExit)
|
2021-04-14 16:24:30 +03:00
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
// The llvm Support classes don't handle reading from stdout of a child
|
|
|
|
// process; otherwise we could avoid using a temp file.
|
2023-12-15 20:16:19 +02:00
|
|
|
std::string ErrMsg;
|
|
|
|
int Res =
|
|
|
|
sys::ExecuteAndWait(Args[0], Args, /*Env=*/std::nullopt, /*Redirects=*/{},
|
|
|
|
/*SecondsToWait=*/0, /*MemoryLimit=*/0, &ErrMsg);
|
2021-04-14 16:24:30 +03:00
|
|
|
if (Res) {
|
2023-12-15 20:16:19 +02:00
|
|
|
if (!ErrMsg.empty())
|
|
|
|
fatalError("llvm-rc: Preprocessing failed: " + ErrMsg);
|
|
|
|
else
|
|
|
|
fatalError("llvm-rc: Preprocessing failed.");
|
2021-04-14 16:24:30 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
static std::pair<bool, std::string> isWindres(llvm::StringRef Argv0) {
|
|
|
|
StringRef ProgName = llvm::sys::path::stem(Argv0);
|
|
|
|
// x86_64-w64-mingw32-windres -> x86_64-w64-mingw32, windres
|
|
|
|
// llvm-rc -> "", llvm-rc
|
|
|
|
// aarch64-w64-mingw32-llvm-windres-10.exe -> aarch64-w64-mingw32, llvm-windres
|
|
|
|
ProgName = ProgName.rtrim("0123456789.-");
|
2021-06-23 14:52:36 +03:00
|
|
|
if (!ProgName.consume_back_insensitive("windres"))
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
return std::make_pair<bool, std::string>(false, "");
|
2021-06-23 14:52:36 +03:00
|
|
|
ProgName.consume_back_insensitive("llvm-");
|
|
|
|
ProgName.consume_back_insensitive("-");
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
return std::make_pair<bool, std::string>(true, ProgName.str());
|
|
|
|
}
|
2017-07-25 00:25:18 +00:00
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
Format parseFormat(StringRef S) {
|
|
|
|
Format F = StringSwitch<Format>(S.lower())
|
|
|
|
.Case("rc", Rc)
|
|
|
|
.Case("res", Res)
|
|
|
|
.Case("coff", Coff)
|
|
|
|
.Default(Unknown);
|
|
|
|
if (F == Unknown)
|
|
|
|
fatalError("Unable to parse '" + Twine(S) + "' as a format");
|
|
|
|
return F;
|
|
|
|
}
|
|
|
|
|
|
|
|
void deduceFormat(Format &Dest, StringRef File) {
|
|
|
|
Format F = StringSwitch<Format>(sys::path::extension(File.lower()))
|
|
|
|
.Case(".rc", Rc)
|
|
|
|
.Case(".res", Res)
|
|
|
|
.Case(".o", Coff)
|
|
|
|
.Case(".obj", Coff)
|
|
|
|
.Default(Unknown);
|
|
|
|
if (F != Unknown)
|
|
|
|
Dest = F;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string unescape(StringRef S) {
|
|
|
|
std::string Out;
|
|
|
|
Out.reserve(S.size());
|
|
|
|
for (int I = 0, E = S.size(); I < E; I++) {
|
|
|
|
if (S[I] == '\\') {
|
|
|
|
if (I + 1 < E)
|
|
|
|
Out.push_back(S[++I]);
|
|
|
|
else
|
|
|
|
fatalError("Unterminated escape");
|
|
|
|
continue;
|
2022-08-26 14:03:36 +03:00
|
|
|
} else if (S[I] == '"') {
|
|
|
|
// This eats an individual unescaped quote, like a shell would do.
|
|
|
|
continue;
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
}
|
|
|
|
Out.push_back(S[I]);
|
|
|
|
}
|
|
|
|
return Out;
|
|
|
|
}
|
|
|
|
|
|
|
|
RcOptions parseWindresOptions(ArrayRef<const char *> ArgsArr,
|
|
|
|
ArrayRef<const char *> InputArgsArray,
|
|
|
|
std::string Prefix) {
|
|
|
|
WindresOptTable T;
|
|
|
|
RcOptions Opts;
|
2017-07-25 00:25:18 +00:00
|
|
|
unsigned MAI, MAC;
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
opt::InputArgList InputArgs = T.ParseArgs(ArgsArr, MAI, MAC);
|
|
|
|
|
2023-03-24 00:24:23 +02:00
|
|
|
Opts.IsWindres = true;
|
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
// The tool prints nothing when invoked with no command-line arguments.
|
|
|
|
if (InputArgs.hasArg(WINDRES_help)) {
|
2021-06-24 14:47:03 -07:00
|
|
|
T.printHelp(outs(), "windres [options] file...",
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
"LLVM windres (GNU windres compatible)", false, true);
|
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (InputArgs.hasArg(WINDRES_version)) {
|
|
|
|
outs() << "llvm-windres, compatible with GNU windres\n";
|
|
|
|
cl::PrintVersionMessage();
|
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string> FileArgs = InputArgs.getAllArgValues(WINDRES_INPUT);
|
|
|
|
FileArgs.insert(FileArgs.end(), InputArgsArray.begin(), InputArgsArray.end());
|
|
|
|
|
|
|
|
if (InputArgs.hasArg(WINDRES_input)) {
|
|
|
|
Opts.InputFile = InputArgs.getLastArgValue(WINDRES_input).str();
|
|
|
|
} else if (!FileArgs.empty()) {
|
|
|
|
Opts.InputFile = FileArgs.front();
|
|
|
|
FileArgs.erase(FileArgs.begin());
|
|
|
|
} else {
|
|
|
|
// TODO: GNU windres takes input on stdin in this case.
|
|
|
|
fatalError("Missing input file");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (InputArgs.hasArg(WINDRES_output)) {
|
|
|
|
Opts.OutputFile = InputArgs.getLastArgValue(WINDRES_output).str();
|
|
|
|
} else if (!FileArgs.empty()) {
|
|
|
|
Opts.OutputFile = FileArgs.front();
|
|
|
|
FileArgs.erase(FileArgs.begin());
|
|
|
|
} else {
|
|
|
|
// TODO: GNU windres writes output in rc form to stdout in this case.
|
|
|
|
fatalError("Missing output file");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (InputArgs.hasArg(WINDRES_input_format)) {
|
|
|
|
Opts.InputFormat =
|
|
|
|
parseFormat(InputArgs.getLastArgValue(WINDRES_input_format));
|
|
|
|
} else {
|
|
|
|
deduceFormat(Opts.InputFormat, Opts.InputFile);
|
|
|
|
}
|
|
|
|
if (Opts.InputFormat == Coff)
|
|
|
|
fatalError("Unsupported input format");
|
|
|
|
|
|
|
|
if (InputArgs.hasArg(WINDRES_output_format)) {
|
|
|
|
Opts.OutputFormat =
|
|
|
|
parseFormat(InputArgs.getLastArgValue(WINDRES_output_format));
|
|
|
|
} else {
|
|
|
|
// The default in windres differs from the default in RcOptions
|
|
|
|
Opts.OutputFormat = Coff;
|
|
|
|
deduceFormat(Opts.OutputFormat, Opts.OutputFile);
|
|
|
|
}
|
|
|
|
if (Opts.OutputFormat == Rc)
|
|
|
|
fatalError("Unsupported output format");
|
|
|
|
if (Opts.InputFormat == Opts.OutputFormat) {
|
|
|
|
outs() << "Nothing to do.\n";
|
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
Opts.PrintCmdAndExit = InputArgs.hasArg(WINDRES__HASH_HASH_HASH);
|
|
|
|
Opts.Preprocess = !InputArgs.hasArg(WINDRES_no_preprocess);
|
|
|
|
Triple TT(Prefix);
|
|
|
|
if (InputArgs.hasArg(WINDRES_target)) {
|
|
|
|
StringRef Value = InputArgs.getLastArgValue(WINDRES_target);
|
|
|
|
if (Value == "pe-i386")
|
|
|
|
Opts.Triple = "i686-w64-mingw32";
|
|
|
|
else if (Value == "pe-x86-64")
|
|
|
|
Opts.Triple = "x86_64-w64-mingw32";
|
|
|
|
else
|
|
|
|
// Implicit extension; if the --target value isn't one of the known
|
|
|
|
// BFD targets, allow setting the full triple string via this instead.
|
|
|
|
Opts.Triple = Value.str();
|
|
|
|
} else if (TT.getArch() != Triple::UnknownArch)
|
|
|
|
Opts.Triple = Prefix;
|
|
|
|
else
|
|
|
|
Opts.Triple = getMingwTriple();
|
2019-01-16 08:09:22 +00:00
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
for (const auto *Arg :
|
|
|
|
InputArgs.filtered(WINDRES_include_dir, WINDRES_define, WINDRES_undef,
|
|
|
|
WINDRES_preprocessor_arg)) {
|
|
|
|
// GNU windres passes the arguments almost as-is on to popen() (it only
|
|
|
|
// backslash escapes spaces in the arguments), where a shell would
|
|
|
|
// unescape backslash escapes for quotes and similar. This means that
|
|
|
|
// when calling GNU windres, callers need to double escape chars like
|
|
|
|
// quotes, e.g. as -DSTRING=\\\"1.2.3\\\".
|
|
|
|
//
|
|
|
|
// Exactly how the arguments are interpreted depends on the platform
|
|
|
|
// though - but the cases where this matters (where callers would have
|
|
|
|
// done this double escaping) probably is confined to cases like these
|
|
|
|
// quoted string defines, and those happen to work the same across unix
|
|
|
|
// and windows.
|
[llvm-windres] Implement the windres flag --use-temp-file
Whether a temp file or a pipe is used for preprocessing is an
internal detail, this flag has a notable effect on the preprocessing
in GNU windres. Without this flag, GNU windres passes command
arguments as-is to popen(), which means they get evaluated by a
shell without being re-escaped for this case. To mimic this,
llvm-windres has manually tried to unescape arguments.
When GNU windres is given the --use-temp-file flag, it uses a
different API for invoking the preprocessor, and this API takes care
of preserving special characters in the command line arguments.
For users of GNU windres, this means that by using --use-temp-file,
they don't need to do the (quite terrible) double escaping of
quotes/spaces etc.
The xz project uses the --use-temp-file flag when invoking
GNU windres, see
https://github.com/tukaani-project/xz/commit/6b117d3b1fe91eb26d533ab16a2e552f84148d47.
However as llvm-windres didn't implement this flag and just
assumed the GNU windres popen() behaviour, they had to use a
different codepath for llvm-windres.
That separate codepath for llvm-windres broke later when llvm-windres
got slightly more accurate unescaping of lone quotes in
0f4c6b120f21d582ab7c5c4f2b2a475086c34938 /
https://reviews.llvm.org/D146848 (fixing a discrepancy to GNU
windres as found in https://github.com/llvm/llvm-project/issues/57334),
and this was reported in
https://github.com/mstorsjo/llvm-mingw/issues/363.
Not touching the implementation of the --preprocessor option
with respect to the --use-temp-file flag; that option is doubly
tricky as GNU windres changed its behaviour in a backwards incompatible
way recently (and llvm-windres currently matches the old behaviour).
(See
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594 and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f;hp=3abbafc2aacc6706fea3e3e326e2f08d107c3672
for the behaviour change.)
Differential Revision: https://reviews.llvm.org/D159223
2023-08-30 23:29:15 +03:00
|
|
|
//
|
|
|
|
// If GNU windres is executed with --use-temp-file, it doesn't use
|
|
|
|
// popen() to invoke the preprocessor, but uses another function which
|
|
|
|
// actually preserves tricky characters better. To mimic this behaviour,
|
|
|
|
// don't unescape arguments here.
|
|
|
|
std::string Value = Arg->getValue();
|
|
|
|
if (!InputArgs.hasArg(WINDRES_use_temp_file))
|
|
|
|
Value = unescape(Value);
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
switch (Arg->getOption().getID()) {
|
|
|
|
case WINDRES_include_dir:
|
|
|
|
// Technically, these are handled the same way as e.g. defines, but
|
|
|
|
// the way we consistently unescape the unix way breaks windows paths
|
|
|
|
// with single backslashes. Alternatively, our unescape function would
|
|
|
|
// need to mimic the platform specific command line parsing/unescaping
|
|
|
|
// logic.
|
|
|
|
Opts.Params.Include.push_back(Arg->getValue());
|
|
|
|
Opts.PreprocessArgs.push_back("-I");
|
|
|
|
Opts.PreprocessArgs.push_back(Arg->getValue());
|
|
|
|
break;
|
|
|
|
case WINDRES_define:
|
|
|
|
Opts.PreprocessArgs.push_back("-D");
|
[llvm-windres] Implement the windres flag --use-temp-file
Whether a temp file or a pipe is used for preprocessing is an
internal detail, this flag has a notable effect on the preprocessing
in GNU windres. Without this flag, GNU windres passes command
arguments as-is to popen(), which means they get evaluated by a
shell without being re-escaped for this case. To mimic this,
llvm-windres has manually tried to unescape arguments.
When GNU windres is given the --use-temp-file flag, it uses a
different API for invoking the preprocessor, and this API takes care
of preserving special characters in the command line arguments.
For users of GNU windres, this means that by using --use-temp-file,
they don't need to do the (quite terrible) double escaping of
quotes/spaces etc.
The xz project uses the --use-temp-file flag when invoking
GNU windres, see
https://github.com/tukaani-project/xz/commit/6b117d3b1fe91eb26d533ab16a2e552f84148d47.
However as llvm-windres didn't implement this flag and just
assumed the GNU windres popen() behaviour, they had to use a
different codepath for llvm-windres.
That separate codepath for llvm-windres broke later when llvm-windres
got slightly more accurate unescaping of lone quotes in
0f4c6b120f21d582ab7c5c4f2b2a475086c34938 /
https://reviews.llvm.org/D146848 (fixing a discrepancy to GNU
windres as found in https://github.com/llvm/llvm-project/issues/57334),
and this was reported in
https://github.com/mstorsjo/llvm-mingw/issues/363.
Not touching the implementation of the --preprocessor option
with respect to the --use-temp-file flag; that option is doubly
tricky as GNU windres changed its behaviour in a backwards incompatible
way recently (and llvm-windres currently matches the old behaviour).
(See
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594 and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f;hp=3abbafc2aacc6706fea3e3e326e2f08d107c3672
for the behaviour change.)
Differential Revision: https://reviews.llvm.org/D159223
2023-08-30 23:29:15 +03:00
|
|
|
Opts.PreprocessArgs.push_back(Value);
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
break;
|
|
|
|
case WINDRES_undef:
|
|
|
|
Opts.PreprocessArgs.push_back("-U");
|
[llvm-windres] Implement the windres flag --use-temp-file
Whether a temp file or a pipe is used for preprocessing is an
internal detail, this flag has a notable effect on the preprocessing
in GNU windres. Without this flag, GNU windres passes command
arguments as-is to popen(), which means they get evaluated by a
shell without being re-escaped for this case. To mimic this,
llvm-windres has manually tried to unescape arguments.
When GNU windres is given the --use-temp-file flag, it uses a
different API for invoking the preprocessor, and this API takes care
of preserving special characters in the command line arguments.
For users of GNU windres, this means that by using --use-temp-file,
they don't need to do the (quite terrible) double escaping of
quotes/spaces etc.
The xz project uses the --use-temp-file flag when invoking
GNU windres, see
https://github.com/tukaani-project/xz/commit/6b117d3b1fe91eb26d533ab16a2e552f84148d47.
However as llvm-windres didn't implement this flag and just
assumed the GNU windres popen() behaviour, they had to use a
different codepath for llvm-windres.
That separate codepath for llvm-windres broke later when llvm-windres
got slightly more accurate unescaping of lone quotes in
0f4c6b120f21d582ab7c5c4f2b2a475086c34938 /
https://reviews.llvm.org/D146848 (fixing a discrepancy to GNU
windres as found in https://github.com/llvm/llvm-project/issues/57334),
and this was reported in
https://github.com/mstorsjo/llvm-mingw/issues/363.
Not touching the implementation of the --preprocessor option
with respect to the --use-temp-file flag; that option is doubly
tricky as GNU windres changed its behaviour in a backwards incompatible
way recently (and llvm-windres currently matches the old behaviour).
(See
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594 and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f;hp=3abbafc2aacc6706fea3e3e326e2f08d107c3672
for the behaviour change.)
Differential Revision: https://reviews.llvm.org/D159223
2023-08-30 23:29:15 +03:00
|
|
|
Opts.PreprocessArgs.push_back(Value);
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
break;
|
|
|
|
case WINDRES_preprocessor_arg:
|
[llvm-windres] Implement the windres flag --use-temp-file
Whether a temp file or a pipe is used for preprocessing is an
internal detail, this flag has a notable effect on the preprocessing
in GNU windres. Without this flag, GNU windres passes command
arguments as-is to popen(), which means they get evaluated by a
shell without being re-escaped for this case. To mimic this,
llvm-windres has manually tried to unescape arguments.
When GNU windres is given the --use-temp-file flag, it uses a
different API for invoking the preprocessor, and this API takes care
of preserving special characters in the command line arguments.
For users of GNU windres, this means that by using --use-temp-file,
they don't need to do the (quite terrible) double escaping of
quotes/spaces etc.
The xz project uses the --use-temp-file flag when invoking
GNU windres, see
https://github.com/tukaani-project/xz/commit/6b117d3b1fe91eb26d533ab16a2e552f84148d47.
However as llvm-windres didn't implement this flag and just
assumed the GNU windres popen() behaviour, they had to use a
different codepath for llvm-windres.
That separate codepath for llvm-windres broke later when llvm-windres
got slightly more accurate unescaping of lone quotes in
0f4c6b120f21d582ab7c5c4f2b2a475086c34938 /
https://reviews.llvm.org/D146848 (fixing a discrepancy to GNU
windres as found in https://github.com/llvm/llvm-project/issues/57334),
and this was reported in
https://github.com/mstorsjo/llvm-mingw/issues/363.
Not touching the implementation of the --preprocessor option
with respect to the --use-temp-file flag; that option is doubly
tricky as GNU windres changed its behaviour in a backwards incompatible
way recently (and llvm-windres currently matches the old behaviour).
(See
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594 and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f;hp=3abbafc2aacc6706fea3e3e326e2f08d107c3672
for the behaviour change.)
Differential Revision: https://reviews.llvm.org/D159223
2023-08-30 23:29:15 +03:00
|
|
|
Opts.PreprocessArgs.push_back(Value);
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (InputArgs.hasArg(WINDRES_preprocessor))
|
[llvm-windres] Change the interpretation of --preprocessor to match Binutils 2.36 (#75391)
Binutils 2.36 had a somewhat controversial change in how the
--preprocessor option was handled in GNU windres; previously, the option
was interpreted as a part of the command string, potentially containing
multiple arguments (which even was hinted at in the documentation).
In Binutils 2.36, this was changed to interpret the --preprocessor
argument as one argument (possibly containing spaces) pointing at the
preprocessor executable.
The existing behaviour where implicit arguments like -E -xc -DRC_INVOKED
are dropped if --preprocessor is specified, was kept.
This was a breaking change for some users of GNU windres, see
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594, and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f.
As multiple years have passed since, the behaviour change seems to be
here to stay, and any users of the previous form of the option have been
forced to avoid this construct. Thus update llvm-windres to match the
new way Binutils of handling this option.
One construct for specifying the path to the preprocessor, which works
both before and after binutils 2.36 (and this change in llvm-windres) is
to specify options like this:
--preprocessor path/to/executable --preprocessor-arg -E
--preprocessor-arg -xc -DRC_INVOKED
2023-12-18 12:31:05 +02:00
|
|
|
Opts.Preprocessor = InputArgs.getLastArgValue(WINDRES_preprocessor);
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
|
|
|
|
Opts.Params.CodePage = CpWin1252; // Different default
|
|
|
|
if (InputArgs.hasArg(WINDRES_codepage)) {
|
|
|
|
if (InputArgs.getLastArgValue(WINDRES_codepage)
|
2021-08-02 14:10:22 +03:00
|
|
|
.getAsInteger(0, Opts.Params.CodePage))
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
fatalError("Invalid code page: " +
|
|
|
|
InputArgs.getLastArgValue(WINDRES_codepage));
|
|
|
|
}
|
|
|
|
if (InputArgs.hasArg(WINDRES_language)) {
|
2021-08-02 14:10:22 +03:00
|
|
|
StringRef Val = InputArgs.getLastArgValue(WINDRES_language);
|
|
|
|
Val.consume_front_insensitive("0x");
|
|
|
|
if (Val.getAsInteger(16, Opts.LangId))
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
fatalError("Invalid language id: " +
|
|
|
|
InputArgs.getLastArgValue(WINDRES_language));
|
|
|
|
}
|
|
|
|
|
|
|
|
Opts.BeVerbose = InputArgs.hasArg(WINDRES_verbose);
|
|
|
|
|
|
|
|
return Opts;
|
|
|
|
}
|
|
|
|
|
|
|
|
RcOptions parseRcOptions(ArrayRef<const char *> ArgsArr,
|
|
|
|
ArrayRef<const char *> InputArgsArray) {
|
|
|
|
RcOptTable T;
|
|
|
|
RcOptions Opts;
|
|
|
|
unsigned MAI, MAC;
|
2017-07-25 00:25:18 +00:00
|
|
|
opt::InputArgList InputArgs = T.ParseArgs(ArgsArr, MAI, MAC);
|
|
|
|
|
|
|
|
// The tool prints nothing when invoked with no command-line arguments.
|
2020-08-05 11:00:21 +03:00
|
|
|
if (InputArgs.hasArg(OPT_help)) {
|
2023-07-06 00:27:37 +03:00
|
|
|
T.printHelp(outs(), "llvm-rc [options] file...", "LLVM Resource Converter",
|
|
|
|
false);
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
exit(0);
|
2017-08-10 16:21:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string> InArgsInfo = InputArgs.getAllArgValues(OPT_INPUT);
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
InArgsInfo.insert(InArgsInfo.end(), InputArgsArray.begin(),
|
|
|
|
InputArgsArray.end());
|
2017-08-10 16:21:44 +00:00
|
|
|
if (InArgsInfo.size() != 1) {
|
|
|
|
fatalError("Exactly one input file should be provided.");
|
|
|
|
}
|
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
Opts.PrintCmdAndExit = InputArgs.hasArg(OPT__HASH_HASH_HASH);
|
|
|
|
Opts.Triple = getClangClTriple();
|
|
|
|
for (const auto *Arg :
|
|
|
|
InputArgs.filtered(OPT_includepath, OPT_define, OPT_undef)) {
|
|
|
|
switch (Arg->getOption().getID()) {
|
|
|
|
case OPT_includepath:
|
|
|
|
Opts.PreprocessArgs.push_back("-I");
|
|
|
|
break;
|
|
|
|
case OPT_define:
|
|
|
|
Opts.PreprocessArgs.push_back("-D");
|
|
|
|
break;
|
|
|
|
case OPT_undef:
|
|
|
|
Opts.PreprocessArgs.push_back("-U");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
Opts.PreprocessArgs.push_back(Arg->getValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
Opts.InputFile = InArgsInfo[0];
|
|
|
|
Opts.BeVerbose = InputArgs.hasArg(OPT_verbose);
|
|
|
|
Opts.Preprocess = !InputArgs.hasArg(OPT_no_preprocess);
|
|
|
|
Opts.Params.Include = InputArgs.getAllArgValues(OPT_includepath);
|
|
|
|
Opts.Params.NoInclude = InputArgs.hasArg(OPT_noinclude);
|
|
|
|
if (Opts.Params.NoInclude) {
|
|
|
|
// Clear the INLCUDE variable for the external preprocessor
|
|
|
|
#ifdef _WIN32
|
|
|
|
::_putenv("INCLUDE=");
|
|
|
|
#else
|
|
|
|
::unsetenv("INCLUDE");
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
if (InputArgs.hasArg(OPT_codepage)) {
|
|
|
|
if (InputArgs.getLastArgValue(OPT_codepage)
|
|
|
|
.getAsInteger(10, Opts.Params.CodePage))
|
|
|
|
fatalError("Invalid code page: " +
|
|
|
|
InputArgs.getLastArgValue(OPT_codepage));
|
|
|
|
}
|
|
|
|
Opts.IsDryRun = InputArgs.hasArg(OPT_dry_run);
|
|
|
|
auto OutArgsInfo = InputArgs.getAllArgValues(OPT_fileout);
|
|
|
|
if (OutArgsInfo.empty()) {
|
|
|
|
SmallString<128> OutputFile(Opts.InputFile);
|
|
|
|
llvm::sys::fs::make_absolute(OutputFile);
|
|
|
|
llvm::sys::path::replace_extension(OutputFile, "res");
|
2024-01-19 00:19:31 -08:00
|
|
|
OutArgsInfo.push_back(std::string(OutputFile));
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
}
|
|
|
|
if (!Opts.IsDryRun) {
|
|
|
|
if (OutArgsInfo.size() != 1)
|
|
|
|
fatalError(
|
|
|
|
"No more than one output file should be provided (using /FO flag).");
|
|
|
|
Opts.OutputFile = OutArgsInfo[0];
|
|
|
|
}
|
|
|
|
Opts.AppendNull = InputArgs.hasArg(OPT_add_null);
|
|
|
|
if (InputArgs.hasArg(OPT_lang_id)) {
|
2021-08-02 14:10:22 +03:00
|
|
|
StringRef Val = InputArgs.getLastArgValue(OPT_lang_id);
|
|
|
|
Val.consume_front_insensitive("0x");
|
|
|
|
if (Val.getAsInteger(16, Opts.LangId))
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
fatalError("Invalid language id: " +
|
|
|
|
InputArgs.getLastArgValue(OPT_lang_id));
|
|
|
|
}
|
|
|
|
return Opts;
|
|
|
|
}
|
|
|
|
|
|
|
|
RcOptions getOptions(const char *Argv0, ArrayRef<const char *> ArgsArr,
|
|
|
|
ArrayRef<const char *> InputArgs) {
|
|
|
|
std::string Prefix;
|
|
|
|
bool IsWindres;
|
|
|
|
std::tie(IsWindres, Prefix) = isWindres(Argv0);
|
|
|
|
if (IsWindres)
|
|
|
|
return parseWindresOptions(ArgsArr, InputArgs, Prefix);
|
|
|
|
else
|
|
|
|
return parseRcOptions(ArgsArr, InputArgs);
|
|
|
|
}
|
|
|
|
|
|
|
|
void doRc(std::string Src, std::string Dest, RcOptions &Opts,
|
|
|
|
const char *Argv0) {
|
|
|
|
std::string PreprocessedFile = Src;
|
|
|
|
if (Opts.Preprocess) {
|
2021-04-14 16:24:30 +03:00
|
|
|
std::string OutFile = createTempFile("preproc", "rc");
|
|
|
|
TempPreprocFile.setFile(OutFile);
|
2023-03-24 12:06:24 +02:00
|
|
|
preprocess(Src, OutFile, Opts, Argv0);
|
|
|
|
PreprocessedFile = OutFile;
|
2021-04-14 16:24:30 +03:00
|
|
|
}
|
|
|
|
|
2017-08-10 16:21:44 +00:00
|
|
|
// Read and tokenize the input file.
|
2017-10-11 20:12:09 +00:00
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>> File =
|
2021-04-14 16:24:30 +03:00
|
|
|
MemoryBuffer::getFile(PreprocessedFile);
|
2017-08-10 16:21:44 +00:00
|
|
|
if (!File) {
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
fatalError("Error opening file '" + Twine(PreprocessedFile) +
|
2017-08-10 16:21:44 +00:00
|
|
|
"': " + File.getError().message());
|
|
|
|
}
|
|
|
|
|
|
|
|
std::unique_ptr<MemoryBuffer> FileContents = std::move(*File);
|
|
|
|
StringRef Contents = FileContents->getBuffer();
|
|
|
|
|
2018-05-09 18:21:03 +00:00
|
|
|
std::string FilteredContents = filterCppOutput(Contents);
|
|
|
|
std::vector<RCToken> Tokens = ExitOnErr(tokenizeRC(FilteredContents));
|
2017-08-10 16:21:44 +00:00
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
if (Opts.BeVerbose) {
|
2017-08-10 16:21:44 +00:00
|
|
|
const Twine TokenNames[] = {
|
|
|
|
#define TOKEN(Name) #Name,
|
|
|
|
#define SHORT_TOKEN(Name, Ch) #Name,
|
2017-11-21 00:23:19 +00:00
|
|
|
#include "ResourceScriptTokenList.def"
|
2017-08-10 16:21:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
for (const RCToken &Token : Tokens) {
|
|
|
|
outs() << TokenNames[static_cast<int>(Token.kind())] << ": "
|
|
|
|
<< Token.value();
|
|
|
|
if (Token.kind() == RCToken::Kind::Int)
|
|
|
|
outs() << "; int value = " << Token.intValue();
|
|
|
|
|
|
|
|
outs() << "\n";
|
|
|
|
}
|
|
|
|
}
|
2017-07-25 00:25:18 +00:00
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
WriterParams &Params = Opts.Params;
|
|
|
|
SmallString<128> InputFile(Src);
|
2017-10-11 20:12:09 +00:00
|
|
|
llvm::sys::fs::make_absolute(InputFile);
|
|
|
|
Params.InputFilePath = InputFile;
|
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
switch (Params.CodePage) {
|
|
|
|
case CpAcp:
|
|
|
|
case CpWin1252:
|
|
|
|
case CpUtf8:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
fatalError("Unsupported code page, only 0, 1252 and 65001 are supported!");
|
2018-05-02 19:43:44 +00:00
|
|
|
}
|
|
|
|
|
2017-09-29 17:14:09 +00:00
|
|
|
std::unique_ptr<ResourceFileWriter> Visitor;
|
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
if (!Opts.IsDryRun) {
|
2017-09-29 17:14:09 +00:00
|
|
|
std::error_code EC;
|
2019-08-15 15:54:37 +00:00
|
|
|
auto FOut = std::make_unique<raw_fd_ostream>(
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
Dest, EC, sys::fs::FA_Read | sys::fs::FA_Write);
|
2017-09-29 17:14:09 +00:00
|
|
|
if (EC)
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
fatalError("Error opening output file '" + Dest + "': " + EC.message());
|
2019-08-15 15:54:37 +00:00
|
|
|
Visitor = std::make_unique<ResourceFileWriter>(Params, std::move(FOut));
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
Visitor->AppendNull = Opts.AppendNull;
|
2017-09-29 17:14:09 +00:00
|
|
|
|
|
|
|
ExitOnErr(NullResource().visit(Visitor.get()));
|
|
|
|
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
unsigned PrimaryLangId = Opts.LangId & 0x3ff;
|
|
|
|
unsigned SubLangId = Opts.LangId >> 10;
|
2020-06-20 23:34:53 +03:00
|
|
|
ExitOnErr(LanguageResource(PrimaryLangId, SubLangId).visit(Visitor.get()));
|
2017-09-29 17:14:09 +00:00
|
|
|
}
|
|
|
|
|
2017-08-18 18:24:17 +00:00
|
|
|
rc::RCParser Parser{std::move(Tokens)};
|
|
|
|
while (!Parser.isEof()) {
|
|
|
|
auto Resource = ExitOnErr(Parser.parseSingleResource());
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
if (Opts.BeVerbose)
|
2017-08-18 18:24:17 +00:00
|
|
|
Resource->log(outs());
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
if (!Opts.IsDryRun)
|
2017-09-29 17:14:09 +00:00
|
|
|
ExitOnErr(Resource->visit(Visitor.get()));
|
2017-08-18 18:24:17 +00:00
|
|
|
}
|
|
|
|
|
2017-10-06 21:30:55 +00:00
|
|
|
// STRINGTABLE resources come at the very end.
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
if (!Opts.IsDryRun)
|
2017-10-06 21:30:55 +00:00
|
|
|
ExitOnErr(Visitor->dumpAllStringTables());
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void doCvtres(std::string Src, std::string Dest, std::string TargetTriple) {
|
|
|
|
object::WindowsResourceParser Parser;
|
|
|
|
|
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>> BufferOrErr =
|
|
|
|
MemoryBuffer::getFile(Src);
|
|
|
|
if (!BufferOrErr)
|
|
|
|
fatalError("Error opening file '" + Twine(Src) +
|
|
|
|
"': " + BufferOrErr.getError().message());
|
|
|
|
std::unique_ptr<MemoryBuffer> &Buffer = BufferOrErr.get();
|
|
|
|
std::unique_ptr<object::WindowsResource> Binary =
|
|
|
|
ExitOnErr(object::WindowsResource::createWindowsResource(
|
|
|
|
Buffer->getMemBufferRef()));
|
|
|
|
|
|
|
|
std::vector<std::string> Duplicates;
|
|
|
|
ExitOnErr(Parser.parse(Binary.get(), Duplicates));
|
|
|
|
for (const auto &DupeDiag : Duplicates)
|
|
|
|
fatalError("Duplicate resources: " + DupeDiag);
|
|
|
|
|
|
|
|
Triple T(TargetTriple);
|
|
|
|
COFF::MachineTypes MachineType;
|
|
|
|
switch (T.getArch()) {
|
|
|
|
case Triple::x86:
|
|
|
|
MachineType = COFF::IMAGE_FILE_MACHINE_I386;
|
|
|
|
break;
|
|
|
|
case Triple::x86_64:
|
|
|
|
MachineType = COFF::IMAGE_FILE_MACHINE_AMD64;
|
|
|
|
break;
|
|
|
|
case Triple::arm:
|
|
|
|
case Triple::thumb:
|
|
|
|
MachineType = COFF::IMAGE_FILE_MACHINE_ARMNT;
|
|
|
|
break;
|
|
|
|
case Triple::aarch64:
|
|
|
|
MachineType = COFF::IMAGE_FILE_MACHINE_ARM64;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
fatalError("Unsupported architecture in target '" + Twine(TargetTriple) +
|
|
|
|
"'");
|
|
|
|
}
|
|
|
|
|
|
|
|
std::unique_ptr<MemoryBuffer> OutputBuffer =
|
|
|
|
ExitOnErr(object::writeWindowsResourceCOFF(MachineType, Parser,
|
|
|
|
/*DateTimeStamp*/ 0));
|
|
|
|
std::unique_ptr<FileOutputBuffer> FileBuffer =
|
|
|
|
ExitOnErr(FileOutputBuffer::create(Dest, OutputBuffer->getBufferSize()));
|
|
|
|
std::copy(OutputBuffer->getBufferStart(), OutputBuffer->getBufferEnd(),
|
|
|
|
FileBuffer->getBufferStart());
|
|
|
|
ExitOnErr(FileBuffer->commit());
|
|
|
|
}
|
|
|
|
|
|
|
|
} // anonymous namespace
|
|
|
|
|
2023-02-10 19:40:56 +00:00
|
|
|
int llvm_rc_main(int Argc, char **Argv, const llvm::ToolContext &) {
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
ExitOnErr.setBanner("llvm-rc: ");
|
|
|
|
|
2022-10-06 05:16:13 +00:00
|
|
|
char **DashDash = std::find_if(Argv + 1, Argv + Argc,
|
|
|
|
[](StringRef Str) { return Str == "--"; });
|
2023-01-04 08:28:45 +01:00
|
|
|
ArrayRef<const char *> ArgsArr = ArrayRef(Argv + 1, DashDash);
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
ArrayRef<const char *> FileArgsArr;
|
|
|
|
if (DashDash != Argv + Argc)
|
2023-01-04 08:28:45 +01:00
|
|
|
FileArgsArr = ArrayRef(DashDash + 1, Argv + Argc);
|
[llvm-rc] Add a GNU windres-like frontend to llvm-rc
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
2021-04-15 14:38:27 +03:00
|
|
|
|
|
|
|
RcOptions Opts = getOptions(Argv[0], ArgsArr, FileArgsArr);
|
|
|
|
|
|
|
|
std::string ResFile = Opts.OutputFile;
|
|
|
|
if (Opts.InputFormat == Rc) {
|
|
|
|
if (Opts.OutputFormat == Coff) {
|
|
|
|
ResFile = createTempFile("rc", "res");
|
|
|
|
TempResFile.setFile(ResFile);
|
|
|
|
}
|
|
|
|
doRc(Opts.InputFile, ResFile, Opts, Argv[0]);
|
|
|
|
} else {
|
|
|
|
ResFile = Opts.InputFile;
|
|
|
|
}
|
|
|
|
if (Opts.OutputFormat == Coff) {
|
|
|
|
doCvtres(ResFile, Opts.OutputFile, Opts.Triple);
|
|
|
|
}
|
2017-10-06 21:30:55 +00:00
|
|
|
|
2017-07-25 00:25:18 +00:00
|
|
|
return 0;
|
|
|
|
}
|