denemo-devel
[Top][All Lists]
Advanced

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

Re: [Denemo-devel] Building 1.0 for windows


From: Richard Shann
Subject: Re: [Denemo-devel] Building 1.0 for windows
Date: Wed, 30 Jan 2013 19:03:41 +0000

On Wed, 2013-01-30 at 10:05 -0600, Jeremiah Benham wrote:
> On 01/29/2013 11:50 AM, Richard Shann wrote:
> > What do you think - shall we make a release of the source code but 
> > wait until we have binaries built from it to announce on various 
> > forums?
> 
> Do you feel like the bug you mention is in the uncross-compiled
> version? 
I am guessing it is caused by something wrong in the building via
cross-compiling.

> If not,  we could always release the binaries later. If we release, we
> can make an additional announcement when the binaries are created.

Yes, and if it proves to be a Denemo source code bug we would release
1.2 as soon as it is fixed.

> 
> I created a gub branch called release-mingw-0.9.6. With it I compiled
> the mingw and master branches of denemo.
> mingw:
>   denemo-1.0.0.~rc.7-7.mingw.exe
> master:
>   denemo-1.0.0.~rc.7-8.mingw.exe
> 
> I tested the mingw out on a windows xp machine. It crashed everytime
> with a popup telling me about project recovery. Whatever I click
> denemo exits. I tried deleting the .denemo-1.xxx dir and it the dialog
> still pops up.
The crashrecovery routine is triggered by the presence of a file

gchar *crash_file = g_build_filename(locatedotdenemo (), 
"crashrecovery.denemo", NULL);

this cannot happen if you successfully deleted the relevant .denemoxxx
directory. Well, of course if the program is already running amok, it
could still happen, more or less anything can.



>  Is it this dialog? I looked at the code in view.c and thought that
> this dialog would probably be better off in its own function. It looks
> suspicious.
It is certainly that - I have never known it to do anything useful. It
dates back to the days when Denemo was full of flaky code. But I don't
suspect it of doing anything evil.

>  Can we run gdb somehow on it.
Yes, when I had a windows partition I did do that. I would get it to
stop on the g_dir_open_utf8() call and find out where it came from.
However, if the problem is really wrongly put together libraries with in
compatible interfaces we are not likely to get anywhere that way - we
would be trying to debug code that was never intended to work together.
It would only be useful if it were some Denemo bug that that was leading
fairly directly to the problem.

>  Ironically, I fixed my wine installation and it ran both branches
> fine (except for a couple of fonts not loading).
Did you see the g_dir_open_utf8() assertion? I am seeing this on all
windows builds, even those that work in other respects. I have gone back
to the vista box and given it a bit of a work-out, it *does* seem to be
working just fine. I have seen it working superficially on xp boxes, but
looking at the denemo-console output showed serious problems.

>  It works better then the linux binary in gtk3 based systems. 
> 
> > 
> > If so, I will go ahead with a last turn of the manual/language
> > update thing and we could freeze the code.
> 
> 
> I will leave that up to you.
Well, I have done all the language and so on stuff - and fixed some
problems with the audio-in code. I've submitted the .pot file to
translation.org, so I suggest we give a week for any final tweaks to the
translations to come in and then build our best binaries with the
version number set and decide then on which things to announce along
with the tarball.

Richard





reply via email to

[Prev in Thread] Current Thread [Next in Thread]