search for: podoptdata

Wait, I have a terrible idea. Why don't we roll our own .init_array style appending section? I think we can make this work for all toolchains we support. We'd have something like: struct PODOptData { const char *FlagName; ... // Common POD stuff, can be initialized at ParseCommandLine time. }; LLVM_SECTION(".llvmopt") PODOptData OptionRegisterer = { "foo_flag", ... }; I know the COFF magic to get the section bounds to form an array, and I know it exists for ELF, but I...

LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library free of static initializers, but before brute-force fixing this problem, I'd like outline the incremental steps that will lead to a desirable long term solution. We want infrastructure in place to provide an evolutionary path. In the near term, clients who need llvm-the-library with

...e ones that don't cause problems because we could be happy just compiling them out. For almost everything else, the implicitly initialized "feature" of llvm::cl isn't all that useful, and is in some cases actively harmful. - Daniel We'd have something like: > > struct PODOptData { > const char *FlagName; > ... // Common POD stuff, can be initialized at ParseCommandLine time. > }; > > LLVM_SECTION(".llvmopt") > PODOptData OptionRegisterer = { "foo_flag", ... }; > > I know the COFF magic to get the section bounds to form an arra...