Re: glib 2.3.3 and Windows

[Hans Breuer <Hans Breuer org>]

At 07:44 26.02.04, J. Ali Harlow wrote:
> On 2004.02.25 23:56 Hans Breuer wrote:
> > At 00:14 25.02.04, J. Ali Harlow wrote:

[...]

> > > My situation is that I have chosen to base the latest application I'm 
> > > writing on glib 2.3.2 on the basis that 2.4.0 would be released in 
> > > plenty of time before I was ready to release my own stable version. This 
> > > now seems in jeopardy.
> > Are you about to release your version very soon, do you think some small
> > build glitches are jeopardy - or did I miss some breakage ?
>
> I attached my win32 implementation of g_child_watch to bug 50296, which
> seemed a sensible place since that was the origin of Matthias's changes.
>
> I think my implementation is much better than yours :-)

Me too ;-) Just commited your implementation.

> Specifically it doesn't get confused if the child exits with code 259
> (STILL_ACTIVE) and it doesn't need yet another thread. There aren't
> many cases where it's actually easier to do something under win32 than
> UNIX, but we might as well take advantage of the few that do exist.
>
> I also opened bug 135386 and attached a fix to add the missing exports
> to glib.def. I see you've added at least some of these, so this can
> probably be closed.
>
> > > Given this, I would like to look at solving these problems if noone else 
> > > more qualified is available to look at these issues this week.
> > I'm certainly not qualified for configure magic, but ...
> >
> > > I attach what I have so far - a patch to glibconfig.h to at least allow 
> > > the build to progress to gmain.c (I don't know if including windows.h 
> > > from glibconfig.h is a good idea yet, so I haven't yet submitted this to 
> > > bugzilla).
> > ... including windows.h in glibconfig.h would cause huge breakage in 
> > application code due to massive namespace clashes (at least in Dia).
>
> Yes, I can't say I'm completely surprised. I see you've just used int
> under msc, which I'd be happy with but Tor seemed to be trying to avoid
> this (apparantly because handles won't fit into ints under win64).

changed to typedef void* GPid, though I don't think win64 isn't an issue
at all yet. I've left out your configure changes cause IIRC
glibconfig.h.win32.in and config.h.win32.in have allways been a merge
of the output of configure (for the mingw32 build) and some manually
tweaking required for the msvc build, which does not use the autotools
at all.

> Personally I advocate making GPid hold ProcessIDs anyway for reasons I
> go into in my comments to 50296. I'd appreciate your views.

If this isn't solved with the patch, please explain further ;)

Thanks,
        Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert