After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 748720 - Missing GTKMM_API for CellLayout
Missing GTKMM_API for CellLayout
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: general
3.16.x
Other Windows
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2015-04-30 17:58 UTC by Mikhail Titov
Modified: 2015-05-06 17:40 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Missing GTKMM_API for CellLayout (901 bytes, application/mbox)
2015-04-30 17:58 UTC, Mikhail Titov 		Details

Description Mikhail Titov 2015-04-30 17:58:11 UTC 
Created attachment 302688 [details]
Missing GTKMM_API for CellLayout

This is related to bug 748719
Comment 1 Kjell Ahlstedt 2015-05-01 15:22:58 UTC 
Bug 570620 (libxml++) and bug 719847 (gtkmm) also describe problems related to
the use (or lack of use) of GLIBMM_API and GTKMM_API.

There are about 200 classes in glibmm. Two of them (Glib::ObjectBase and
Glib::Object) are declared with GLIBMM_API.
There are more than 200 classes in gtkmm. Two of them (Gtk::Object and
Gtk::TreeViewColumn) are declared with GTKMM_API.

Now you say that Glib::Interface needs GLIBMM_API, and that
Gtk::CellLayout needs GTKMM_API.

Can you or anyone else explain to someone who doesn't use gtkmm on Windows, why
some classes need GLIBMM_API/GTKMM_API, but most classes don't?
Comment 2 Mikhail Titov 2015-05-04 18:32:06 UTC 
Kjell, from what I understand declaring a class this way is only necessary when data are exported from DLL. From what I understand this is not the case with allMM things. Therefore as of right now the problem is the inconsistency. I did try removing such class declarations and everything compiles fine without warnings.

However there is another issue that Fan brought in bug 719847. That is to ditch gendef tool to generate function export list and use __declspec(dllexport) on Win32. I agree that this is the way to go instead of gendef. However it is a major undertaking.

So adding "missing" definition is the minor step towards ditching gendef in the future. And I think it is easier to mark entire class as exported rather than individual member functions even when we have no data exported.