[libcxx-commits] [PATCH] D100221: [libcxx] [test] Add a separate 'windows-dll' feature to check for

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added inline comments.


================
Comment at: libcxx/utils/libcxx/test/features.py:153
   Feature(name='windows', when=lambda cfg: '_WIN32' in compilerMacros(cfg)),
+  Feature(name='windows-dll', when=lambda cfg: '_WIN32' in compilerMacros(cfg) and cfg.enable_shared),
   Feature(name='linux', when=lambda cfg: '__linux__' in compilerMacros(cfg)),
----------------
ldionne wrote:
> We don't want to use `.enable_shared` here. `.enable_shared` is part of the old config which I'm trying to get rid of one step at a time.
> 
> Is there a way to implicitly detect that we're linking against the DLL without being passed that information through `cfg.enable_shared`?
> 
> Alternatively, something we could explore is add a feature that tells us whether the library is linked statically or dynamically (regardless of the platform). Your feature check would then become `windows && libcxx-linked-dynamically`.
> Is there a way to implicitly detect that we're linking against the DLL without being passed that information through cfg.enable_shared?

We could source the headers and see if `_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS` is defined or not; it's a bit less direct but should be reliable in practice. (The fact that that define indicates static/shared mode is a windows specific bit though.)

> Alternatively, something we could explore is add a feature that tells us whether the library is linked statically or dynamically (regardless of the platform). Your feature check would then become windows && libcxx-linked-dynamically.

I guess that would work - but that boils down to the original issue - I'm not allowed to use the "old config", but I'm not quite familiar enough with the separation between old and new here, and what the actually allowed way of passing info to the new test configure system is.

I presume we're able to introspect the build env by looking for defines and such, but e.g. for non-windows configurations, the fact whether we're building isn't visible in headers. How would you suggest we find the information in that case, and pass it from the parts of the system where we know for sure (where we have the `enable_shared` variable today)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100221/new/

https://reviews.llvm.org/D100221