Re: Test Modules

[Tristan Van Berkom <tristanvb openismus com>]

On Wed, 2013-03-06 at 12:41 +0000, John Emmas wrote:
> On 6 Mar 2013, at 12:14, Tristan Van Berkom wrote:
>
> > Is this question stemming from the fact that you got glib to
> > compile using MSVC, where I suppose you are hacking the source
> > tree severely and not using the autotools/makefiles at all ?
>
> I wouldn't say I've hacked anything too severely Tristan.  Glib already contains projects for building with 
> Visual Studio.  I've just extended them a bit - so that I can build everything (including the various 
> auto-generated files etc) from a Visual Studio project.  Of course, I need to have Perl and Python 
> installed too but autoconf can be skipped (there are already some "config.*.msc" type files available in 
> the distro).
>
>
> > I do recall there was a time that compiling glib with MSVC
> > was needed in order to create more compatible binaries, is
> > this still the case ?
>
> Undoubtedly, yes.  If you build the binaries with MinGW, then later change something and rebuild, MinGW 
> does not seem to guarantee that the second build will use the same ordinal values as your first build (in 
> each DLL).  It's a great recipe for DLL Hell.

This is seriously unfortunate, if glib maintainers need to maintain an
alternate build system to compile glib on win32, that is a serious
problem (considering we are having a hard time already just to get
win32 related patches upstreamed in glib/gtk+).

> > is there any reason to not use a
> > more standard/friendly toolchain like MSYS/mingw where
> > the same configure.ac/Makefiles can be used without modification ?
>
> In my case there are 2 reasons:-  1)  I need to be able to debug all my code using Visual Studio's 
> debugger.  2) MinGW uses the CRT from VC6.0 which is nearly 20 years old now and it's only a matter of time 
> before Microsoft makes it obsolete.

Is '2' really a problem ? I would think that using the earliest ABI
possible is intentionally done by mingw maintainers, in order to support
as many variants of win32 as possible, right ?

As for 1, I think the bigger problem here is really about MinGW, if we
don't trust the compatibility of the dlls it generates, that's really
a bug that should be fixed in MinGW.

Working around this and trying to maintain multiple build systems
is something I think we all want to avoid (i.e. there's no way I
can see that we can afford to maintain this double-standard in the
long run).

FWIW, any time I've created win32 packages of glib based programs,
I've always used a technique which bundles the glib dll together
with the program I wish to distribute on win32 (avoiding any
sharing of prebuilt glib dlls).

While this approach to distribution is sub-optimal (and results
in overly-huge distributions for a single program), I would rather
encourage this approach until MinGW dll compatibility issues can
be fixed... than to push glib maintainers to support a double
standard of build techniques.

To be clear, personally I think portability is a high priority
for us and I take it seriously... in order to protect/ensure
portability in the long term we need to lower the bar of entry
to doing so (i.e. we need make things easier on glib maintainers
and developers), not heighten it.

That said, I'm not a designated glib maintainer, perhaps Ryan
and others have another view on this.

Best,
    -Tristan

> Thanks.
>
> John
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list