Re: [GnomeMeeting-devel-list] Ekiga WIN32

[Julien PUYDT <jpuydt free fr>]

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 
the trick.

> Changes to the configuration files:
> configure.in:
> 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 
already-fixed issues.

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 
> version.
> Finally, Win32 installation of the translations must not have a DATADIRNAME 
> directory.

I haven't taken the time (yet) to diff your configure.in against ours to 
check what you did.

> help/Makefile.am:
> 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.

> Makefile.am:
> 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.

> pixmaps/Makefile.am:
> 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.

> src/Makefile.am:
> 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 
> complete.

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!

Snark