Re: [GnomeMeeting-devel-list] Ekiga WIN32
- From: Julien PUYDT <jpuydt free fr>
- To: GnomeMeeting development mailing list <gnomemeeting-devel-list gnome org>
- Subject: Re: [GnomeMeeting-devel-list] Ekiga WIN32
- Date: Thu, 25 May 2006 18:42:05 +0200
Michael Rickmann a �it :
Here are my suggestions. Since I think that the Ekiga Win32 packaging deserves
a bit more attention in CVS I have tried to change Ekiga's configuration
files that they can be used for Linux and Win32 builds.
Hmmm... hopefully, the build differences should only be minimal : after
all the code is mostly the same.
Note: to build this
you need a fairly recent intltool. I use intltool_0.35 from Ubuntu Dapper.
I put a few files into Ekiga's win32 directory. ekiga.ico, INSTALL_Gtk.txt
(both exist for a long time), ekiga.rc (resource file from me, includes icon
and stuffs information into the executable, right click and choose
properties), Makefile (only compiles the resource). If you agree, please
check ekiga.rc for political correctnes.
The only thing I see wrong in ekiga.rc is that it hardcodes the
executable as being "ekiga.exe" ; perhaps some autotools magic would do
Changes to the configuration files:
I have introduced CVS_VERSION as a new AC_DEFINE variable because I think that
we will need some means to identify the Win32 various Win32 executables which
we are going to release. Via ekiga.rc it will end up in ekiga.exe.
Well, in fact I was pondering a similar trick, but also for the GNU/*
and *BSD version : there has been recently a few bug reports on 15 days
old snapshots, which took time to track down to see they really were
If we have the executable spit out that it's a cvs version of
2002-10-03, and seeing it in a bug reported the 2012-11-24, we would
close it as INVALID right away. If the issue is still current, it has to
be checked on a *recent* snapshot.
Next, configure.in already contains code to identify the target-OS. I have
moved this is to the begining of the file. Then all default config values,
installation directories and subsequent checks can be handled OS specific
(differences mainly for pwlib and opal). For checking the Opal version also
in Win32 I had to extend the diff/opal_configure.ac for extracting the
Finally, Win32 installation of the translations must not have a DATADIRNAME
I haven't taken the time (yet) to diff your configure.in against ours to
check what you did.
As already reported to this list, I could not convince the included
gnome-doc-utils.make to provide the manual in html or xhtml format. So I have
created a new target doc-xhtml: and provided my rule, which converts the
index.xml files to several xhtml files.
Sigh. If you report a bug on this, I'll assign it to myself, and may
think about digging this through.
SUBDIRS additions win32 (resource), help (first stage, xml generation)
Legalism_DATA: I think files like Changelog, COPYING, LICENSE should be part
of any distribution of a GNU program, also for Windows, so install them.
I'd say yes.
pixmap_DATA: We only need to install ekiga-logo.png here. The other image is
already installed by Makefile.am to the correct place.
I'd say ok.
In Win32, we do not need ekiga-config-tool.
We have to link the resource object though.
Again some autotools magic seems needed.
This should releave the Win32 build process a bit and make the package more
This is high priority, since most of the feedback we had for the win32
port wasn't about bugs, but it being hard to install (!).
Speaking of which, I have to congratulate you : my port was decent, you
made it good!
] [Thread Prev