CMakeDetectLibraryType: add module to detect library types

changed milestone to %3.21.0

added workflow:wip label

This will need a cycle on the stage to find out platforms that need logic added to the module (and for which I do not have access to). Test failures should be limited to the new RunCMake.CMakeDetectLibraryType test, so interference should be easy to discern.

Is this locale-sensitive?

I doubt it, but I don't know for sure.

To provide a feature like this in upstream CMake, I'd much rather it be in the C++ implementation and provided by a command, as we do for file(GET_RUNTIME_DEPENDENCIES).

Is file(DETECT_LIBRARY_TYPE) sufficient? In any case, nailing the test suite down with CMake code seems like a good first step.

That name is fine for now.

Do you mean you want to stage this with the module's implementation to get the test suite working, and then port to C++ before merging?

Do you mean you want to stage this with the module's implementation to get the test suite working, and then port to C++ before merging?

Yes. I'm sure there are platforms which mirror Windows and need tooling to determine the difference since the static library suffix is the same as the import library suffix. AIX comes to mind, but there are likely others.

Knowing if that DLL name string is locale-dependent would also be nice (the stage has different locale envs, right?).

I don't think our nightly tests have any Windows machines with non-English locales.

Anyway, go ahead and stage this when CI is happy.

I added the blocked label as a reminder not to merge this until the implementation is updated.

added workflow:in-review label and removed workflow:wip label

added triage:blocked label

added 1 commit

• abd7713c - CMakeDetectLibraryType: add module to detect library types

Compare with previous version

added 1 commit

• aa3dbbd6 - CMakeDetectLibraryType: add module to detect library types

Compare with previous version

added 1 commit

• f5c93b50 - CMakeDetectLibraryType: add module to detect library types

Compare with previous version

added 1 commit

• e2e34de4 - CMakeDetectLibraryType: add module to detect library types

Compare with previous version

Staging to see what the variety of platforms tested elsewhere have to say about the code. Once the test suite is figured out, a C++ implementation can follow.

The CI pipeline isn't 100% complete, but the test in question passed already on the Xcode job.

Do: stage

Issues found (CDash link):

• warnings from the example code (fixed locally)
• nmake outputs a path to stderr? (!5828 (merged))
• cygwin logic needs fixed (needs investigation)
• bcc has no dumpbin (deferring to the C++ impl)
• watcom did not make a .lib file (symbol export details; fixed locally)

Do: unstage

bcc has no dumpbin

An implementation in C++ may be able to actually parse the file directly.

Mmm, fun. What to do about the watcom missing the .lib file? Is CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS not working with that compiler?

I think the Cygwin test could be fixed by testing the longest extensions before the shorter extensions. Not sure how to silence the llvm-nm.exe output from nmake though.

For watcom, see my inline comment in ByContent.cmake.

The llvm-nm output is due to leftover debugging code. !5828 (merged) removes it. If you stop using CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS and add proper dllexport markup, that code path won't be used anyway.

added workflow:nightly-testing label and removed workflow:in-review label

added workflow:wip label and removed workflow:nightly-testing label

Closing for now. Please re-open when ready to continue work.

closed

added workflow:expired label and removed workflow:wip label