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