adamreeve commented on code in PR #41599:
URL: https://github.com/apache/arrow/pull/41599#discussion_r1596194136
##########
c_glib/arrow-glib/array-builder.h:
##########
@@ -22,70 +22,97 @@
#include <arrow-glib/array.h>
#include <arrow-glib/decimal.h>
#include <arrow-glib/interval.h>
+#include <arrow-glib/visibility.h>
G_BEGIN_DECLS
#define GARROW_TYPE_ARRAY_BUILDER (garrow_array_builder_get_type())
+GARROW_EXPORT
G_DECLARE_DERIVABLE_TYPE(
GArrowArrayBuilder, garrow_array_builder, GARROW, ARRAY_BUILDER, GObject)
struct _GArrowArrayBuilderClass
{
GObjectClass parent_class;
};
+GARROW_EXPORT
GArrowDataType *
garrow_array_builder_get_value_data_type(GArrowArrayBuilder *builder);
+
+GARROW_EXPORT
GArrowType
garrow_array_builder_get_value_type(GArrowArrayBuilder *builder);
+GARROW_EXPORT
GArrowArray *
garrow_array_builder_finish(GArrowArrayBuilder *builder, GError **error);
GARROW_AVAILABLE_IN_2_0
+GARROW_EXPORT
Review Comment:
This is what I was originally thinking of doing, but then I was worried
about how this works with the different garrow libraries. We'd probably need
separate available/deprecated macros per library like:
```
GARROW_AVAILABLE_IN_XXX
GARROW_DEPRECATED_IN_XXX
GARROW_DATASET_AVAILABLE_IN_XXX
GARROW_DATASET_DEPRECATED_IN_XXX
GARROW_FLIGHT_AVAILABLE_IN_XXX
GARROW_FLIGHT_DEPRECATED_IN_XXX
GARROW_FLIGHT_SQL_AVAILABLE_IN_XXX
GARROW_FLIGHT_SQL_DEPRECATD_IN_XXX
...
```
That way when you build eg. arrow-dataset-glib and include headers from
arrow-glib, they can correctly get the `dllimport` attribute while code in
arrow-dataset-glib gets `dllexport`.
Maybe I should look at integrating that Python script from GLib to reduce
the boilerplate required. What do you think?
--
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]
