This is an archive of the discontinued LLVM Phabricator instance.

[cmake] Properly support target properties.
ClosedPublic

Authored by stephenneuendorffer on Aug 15 2021, 5:20 PM.

Details

Summary

It's sometimes useful to use these directives when dealing with
external projects:
target_link_directories
target_link_libraries
target_include_directories

However, under certain circumstances,
llvm_add_library can generate multiple targets. We need to transfer
these properties to the new targets. Note that using a generator
expression is necessary because these properties will only be set
after llvm_add_library is called.

Diff Detail

Event Timeline

stephenneuendorffer requested review of this revision.Aug 15 2021, 5:20 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 15 2021, 5:20 PM
stellaraccident accepted this revision.Aug 15 2021, 5:35 PM

Read my mind - was meaning to do this very change last week but ran out of time. How much further are you going? I'd ultimately like our targets to all have proper include/link directories defined so we don't need to do so much global munging.

I also frequently run into the problem that when object libraries are involved, you can only set compile flags on the object library, but that requires knowing whether an object library was used to define the target. It makes writing generic utilities brittle - and worse: in MLIR we often decide to use an object library or not based on what link mode is in use (and if not xcode). I haven't quite convinced myself that this forwarding trick is the right thing for such cases.

This revision is now accepted and ready to land.Aug 15 2021, 5:35 PM
bondhugula accepted this revision.Aug 15 2021, 8:58 PM

Thanks for fixing this!

llvm/cmake/modules/AddLLVM.cmake
489

Nit: terminate with a full stop - here and below.

533

Is there something to fix for target_link_libraries?
target_link_directories is to be rarely used per https://cmake.org/cmake/help/latest/command/target_link_libraries.html#command:target_link_libraries
Instead it's target_link_libraries is preferred.

Read my mind - was meaning to do this very change last week but ran out of time. How much further are you going? I'd ultimately like our targets to all have proper include/link directories defined so we don't need to do so much global munging.

I'm not necessarily doing more with this.. mostly trying to help Uday :)

I also frequently run into the problem that when object libraries are involved, you can only set compile flags on the object library, but that requires knowing whether an object library was used to define the target. It makes writing generic utilities brittle - and worse: in MLIR we often decide to use an object library or not based on what link mode is in use (and if not xcode). I haven't quite convinced myself that this forwarding trick is the right thing for such cases.

Yeah, I definitely don't think it's the right thing to blindly forward *ALL* the myriad target properties. But I convinced myself that at least in the short term this was the right thing to do small... Let's start by expanding your handling of shared libraries to libMLIR.so, then we can see how it can be used to cleanup the bigger LLVM issues.

stephenneuendorffer retitled this revision from [cmake] properly support target_link_directories and target_include_directories to [cmake] Properly support target properties..
stephenneuendorffer edited the summary of this revision. (Show Details)
stephenneuendorffer marked 2 inline comments as done.Aug 16 2021, 1:28 PM
This revision was automatically updated to reflect the committed changes.