[PATCH] D16544: [libcxx] Framework to allow testing of static libc++abi

Ben Craig via cfe-commits cfe-commits at lists.llvm.org
Mon Apr 18 13:00:43 PDT 2016


bcraig added a comment.

In http://reviews.llvm.org/D16544#403273, @EricWF wrote:

> Just spitballing but have you considered simply passing the full path, including the library name, to LIT? Instead of needing `enable_shared` variables we would simply use the named library, be it DSO or archive.


I agree that this would be nice.  I don't really like the nest of if / else statements that I currently have in place.  However, I have now attempted to do this, and failed.  My cmake-fu just isn't strong enough.

My approach was to populate variables like so...

  get_target_property(LIBCXXABI_FULL_LIB_PATH cxxabi_static LOCATION)
  get_target_property(LIBCXXABI_FULL_LIB_PATH cxxabi_shared LOCATION)
  get_target_property(LIBCXX_FULL_LIB_PATH cxx LOCATION)

... and then to plumb that through lit.site.cfg.in.  This would work great if the core of cxxabi and cxx were processed first, followed by their respective tests.  Unfortunately, cxxabi and it's tests get processed before cxx gets processed.  This means that I can't rely on cxx's CMakeLists.txt to populate a path on behalf of cxxabi.  I could attempt to rebuild the path from the pieces of information that I do have access to, but that seems really hacky.

Note that getting a full path in doesn't remove all the if / elif complexity in getting cxx[abi] to the link line.  If no desired path exists in the config, then something like -lc++ or -lc++abi still needs to be passed in.  This is to handle the case where someone is building one of libcxx[abi] without the counterpart being available.  We don't know the absolute path to the respective library, but it is (presumably) in the library path.


http://reviews.llvm.org/D16544





More information about the cfe-commits mailing list