[lldb][test][NFC] Document DYLIB_NAME Makefile variable #112735
Conversation
|
@llvm/pr-subscribers-lldb Author: Michael Buch (Michael137) ChangesGot caught out by this because simply specifying Full diff: https://github.com/llvm/llvm-project/pull/112735.diff 1 Files Affected:
diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
index f81db9bc06d8a8..a2a8ae504053c6 100644
--- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -13,6 +13,13 @@
# the building of the a.out executable program. For example,
# DYLIB_ONLY := YES
#
+# When specifying one of the DYLIB_*_SOURCES variables, DYLIB_NAME
+# controls the name of the produced dylib. E.g., if set to "foo",
+# the generated dylib will be called "foo.<platform-specific-extension>",
+# which on Darwin will be "foo.dylib".
+#
+# DYLIB_NAME := foo
+#
# Specifying FRAMEWORK and its variants has the effect of building a NeXT-style
# framework.
# FRAMEWORK := "Foo"
|
| # When specifying one of the DYLIB_*_SOURCES variables, DYLIB_NAME | ||
| # controls the name of the produced dylib. E.g., if set to "foo", | ||
| # the generated dylib will be called "foo.<platform-specific-extension>", | ||
| # which on Darwin will be "foo.dylib". |
There was a problem hiding this comment.
This is interesting. LLDB makes an assumption that a module named foo will be turned onto libfoo.dylib on Darwin. See Platform::GetFullNameForDylib
There was a problem hiding this comment.
good catch! it was meant to be libfoo for the darwin example :)
There was a problem hiding this comment.
Technically, the "lib" part is platform specific as well. Windows does not have that convention. Libraries (at least, those that aren't very obviously unixy in origin) don't have it:
There was a problem hiding this comment.
Yup, reworded to make it clear this is platform dependent (with an example of how it would look like on Darwin)
| # When specifying one of the DYLIB_*_SOURCES variables, DYLIB_NAME | ||
| # controls the name of the produced dylib. E.g., if set to "foo", | ||
| # the generated dylib will be called "foo.<platform-specific-extension>", | ||
| # which on Darwin will be "foo.dylib". |
There was a problem hiding this comment.
Technically, the "lib" part is platform specific as well. Windows does not have that convention. Libraries (at least, those that aren't very obviously unixy in origin) don't have it:
| # When specifying one of the DYLIB_*_SOURCES variables, DYLIB_NAME | ||
| # controls the (platform-dependent) name of the produced dylib. E.g., | ||
| # on Darwin, if "DYLIB_NAME := foo", the generated dylib will be called | ||
| # "foo.dylib". |
There was a problem hiding this comment.
I think this is still missing the lib portion?
There was a problem hiding this comment.
whoops, forgot about that, thanks
4 participants
Got caught out by this because simply specifying
DYLIB_CXX_SOURCES(without specifyingDYLIB_NAME) resulted in linker errors because the dylib was never built (and linked). We should probably make that a Makefile error (though I haven't audited when exactly not specifyingDYLIB_NAMEis valid; looked like that can happen when we specifyFRAMEWORK).