Re: glib 2.3.3 and Windows

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 and 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 ;)


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]