paleolimbot commented on code in PR #719:
URL: https://github.com/apache/arrow-nanoarrow/pull/719#discussion_r1991972772
##########
src/nanoarrow/nanoarrow.h:
##########
@@ -139,6 +139,20 @@
#endif
+#if (defined _WIN32 || defined __CYGWIN__) && defined(NANOARROW_BUILD_DLL)
+#if defined(NANOARROW_EXPORT_DLL)
+#define NANOARROW_DLL __declspec(dllexport)
+#else
+#define NANOARROW_DLL __declspec(dllimport)
+#endif // defined(NANOARROW_EXPORT_DLL)
+#elif !defined(NANOARROW_DLL)
+#if __GNUC__ >= 4
+#define NANOARROW_DLL __attribute__((visibility("default")))
+#else
+#define NANOARROW_DLL
+#endif // __GNUC__ >= 4
+#endif
Review Comment:
Thanks for taking a look!
> To avoid keeping this up to date, I would recommend the usage of
GenerateExportHeader
I think the main reason I'd like to avoid this is that CMake is one of three
supported ways of consuming nanoarrow (CMake, meson, make a single-file bundle
and use your existing build system).
> is there a reason we want to install static and shared in parallel
This seems to be what other libraries of our size/function are doing (e.g.,
zstd, ADBC, Arrow), and I think installing both in parallel works well for
distributing via something like Homebrew (which often provides shared and
static options to link against so that you can use it to distribute things like
R packages and Python wheels). I think the main advantage comes when trying to
link against a library from something that is not CMake but I'm not an expert
here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
