Building XFCE on Cygwin
Brian J. Tarricone
bjt23 at cornell.edu
Tue Jul 13 19:33:28 CEST 2004
On Tue, 13 Jul 2004, Maarten Boekhold wrote:
> OK, partial success. If I add G_MODULE_EXPORT and G_MODULE_IMPORT in
> appropriate places, #include <gmodule.h> in plugin.c and hack libtool to
> include 'plugin.def' when linking, things compile and execute correctly.
>
> So, there's a few things to decide:
> (1) Can we add G_MODULE_{EXPORT|IMPORT} to all relevant functions
sounds fine to me.
> (2) How do we pass the .def file through libtool to the linker
you could also try whatever_LIBADD, or maybe something like this:
if HAVE_CYGWIN
whatever_LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS $(CFLAGS) \
$(AM_LDFLAGS) $(LDFLAGS) $(def_file) -o $@
endif
where HAVE_CYGWIN would be defined by an AM_CONDITIONAL() in
configure.ac. i took the variable list there from the LINK= line in
libxfcegui4's generated Makefile, so it may need to be tweaked
see here for details about automake variables:
http://www.gnu.org/software/automake/manual/html_mono/automake.html#Program%20and%20Library%20Variables
> (3) How do we handle maintaining this .def file
>
> The .def file is specific to the executable that *loads* the module,
> i.e. mcs-manager and panel. So ideally the .def files are a part of
> those two directory trees. But in this way you create a dependency
> between the plugin sources and mcs-manager/panel sources, which is not
> good. And it wouldn't work at all with 3rd party plugins. Another option
> is to install the .def files somewhere (${prefix}/share?), and modify
> the plugin Makefile.am's so that they read the .def files from there.
> Which brings us back to issue (2)...
i don't think this is a problem. the plugin sources are dependent on
the mcs-manager or panel header files. the .def file could be installed
like just another header (on win32 anyway). the problem is that we'll
need some automake magic so that the $(def_file) variable in Makefile.am
gets populated with the _full path_ to this file.
on the other hand, we can distribute it as data (e.g.,
/usr/share/xfce4/devel/plugin.def), and then plugin authors can
copy and include this with their plugin. if exports are added to the
panel later (they shouldn't be, but let's just say...), it really
doesn't matter if the plugin's copy gets updated since the plugin
wouldn't be using them anyway (obviously, if the plugin author decides
to use one of these new interfaces, they have to get a new plugin.def
file).
>
> Any suggestions/comments?
>
> Maarten
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://lunar-linux.org/mailman/listinfo/xfce4-dev
>
>
More information about the Xfce4-dev
mailing list