[LLVMdev] Fixing LLVM's CMake interface before LLVM3.5 release

Óscar Fuentes ofv at wanadoo.es
Thu Jul 17 08:18:39 PDT 2014


Hello. Original author of the LLVM CMake build system here.

Dan Liew <dan at su-root.co.uk> writes:

> I've been playing [1] with the newly introduced CMake interface for
> using exported LLVM CMake targets (e.g. the LLVMSupport library) in
> CMake projects and although it works there are a few things I think we
> should fix before the LLVM 3.5 release.
>
> Here are the current issues I see that I'd like to discuss.
>
> Just to clarify by "Targets" I mean targets in the CMake sense (e.g..
> an executable or a library)
>
> 1 - We currently have both the old way (i.e.
> llvm_map_components_to_libraries() as in [2] ) and the new way of
> using built LLVM targets in CMake projects in trunk. I think we should
> at some point remove the llvm_map_components_to_libraries() stuff
> because it's messy. I'm not convinced it should be done in the LLVM
> 3.5 release because it would probably be nicer to announce for LLVM
> 3.5 that the old way is deprecated and remove it in LLVM 3.6 to give
> clients more time to cope with the change. Either way we need to
> decide on a plan for this. Thoughts?

llvm_map_components_to_libraries et al. was created because I opted for
a method that allows to "export" complex heuristics to the installed
build and that works on the unistalled build too. That means that I
leaned towars implementing our own logic for linking LLVM's into the
client code rather than relying on what CMake alone provided at the
time. This was for the sake of being more flexible and future-proof.

If what CMake provides is good enough for current and future LLVM usage
requirements, I guess that llvm_map_components_to_libraries can be
removed. (Please note that I'm not the current maintainer, so this is
just personal opinion.)

[snip]

I'll not comment on the rest of your message and leave that to the
maintainers, except for a nitpick:

> 4. Why don't we expose any of the CXXFLAGS in the CMake interface?
>
> To use LLVM libraries as a client at minimum ``-std=c++11 -f-no-rtti``
> are needed.

-fno-rtti is not really *required* for using LLVM. Some LLVM parts
require it (mostly those that are used by deriving an LLVM class.) For
instance, I have a JIT engine implemented across multiple files and only
one of those (amounting to less than 100 lines) require -fno-rtti.

> This information is shown by the ``llvm-config --cxxflags``

That information shows (some of) the global flags used for building
LLVM. Applying those flags on your client code would "guarantee" that
you will be free from some minor annoyances, but it is nor really
required to everywhere apply all those flags for using LLVM, as
mentioned above.

[snip]




More information about the llvm-dev mailing list