[Geany-Devel] Ping on Bug #943 - windows build command

[Nick Treleaven]

On 05/10/2013 15:40, Matthew Brush wrote:
> On 13-10-05 07:06 AM, Nick Treleaven wrote:
>> On 05/10/2013 14:59, Nick Treleaven wrote:
>>>> I don't remember seeing any bug reports for this, so it's possible it's
>>>> limited to you or the specific application you were using, maybe a bug
>>>> in a certain version of DMD? The commit messages doesn't explain what
>>>> the actual root of the problem was or why it could not be fixed
>>>> properly, or what was tried to fix it before abandoning the existing
>>>> code.
>>>
>>> It was last year, but I think it wasn't just with dmd, although that
>>> triggered it the most, and it only happened when dmd wrote more than a
>>> certain amount to stderr (cascading errors). It was very suspicious that
>>> the custom spawn code works until there are too many errors, at least
>>> with dmd.
>>
>> One person reported it on the devel list. See:
>> http://lists.geany.org/pipermail/devel/2011-July/004845.html
>>
>> Unfortunately I missed that mail at the time, but I tried the provided
>> fix before committing my system() change, and I remember it didn't fix
>> all the issues with blocking and/or hanging Geany I had.
>>
>
> That was going to be my guess for the deadlock, once the buffers fill up
> they have to be drained or else can't keep writing to input. The same
> issue should apply to any spawning method we use probably (ie. GSpawn).

Did we get deadlock with g_spawn? I'm only aware of missing output.

> So with the pull request adding system() as a fallback/hidden
> preference, maybe we could just drop the win32 API code altogether,
> switch back to using the same codepath as all platforms (ie. GLib async
> spawning) and if people experience issues, we can use as further data
> points to troubleshoot GLib async spawning and we can recommend they try
> the system() option[1] as a workaround?

system() is *synchronous*, so we couldn't remove the SYNC_SPAWN code and 
have it as an option.

> IMO, any function in our code base prefixed with _broken, that no one
> wants to touch, and looses platform-independence for our code, should
> just be deleted[2] :)

I thought you said it was most important to fix the common case, that's 
why I made the PR.

> BTW, did you try undefining SYNC_SPAWN lately to see if async spawning
> still doesn't work for you now? If so and it doesn't, what Windows
> version and GLib versions do you have?

I just tried it. Running build on a C file:

gcc -Wall -c "build.c" (in directory: C:\git\geany\src)
Compilation failed.
gcc: error: "build.c": Invalid argument
gcc: fatal error: no input files
compilation terminated.

No idea why gcc says that, also tried for another file in parent directory.

Running build on a D file just says 'Compilation failed' without 
reporting the line compilation fails on.

Windows Vista. GTK 2.22.0, GLib 2.26.0.

Also if you want to make the argument that it might be fixed in newer 
versions, I would appreciate if you quoted something plausible that got 
fixed upstream in Git or in the release notes. To my knowledge no 
significant work has been done on it in years. See:

https://git.gnome.org/browse/glib/log/glib/gspawn-win32.c
https://git.gnome.org/browse/glib/log/glib/gspawn-win32-helper.c

> Cheers,
> Matthew Brush
>
> [1]: And maybe fix it so it does cmd.exe quoting properly.

Feel free to look at it.

> [2]: Of course it's in Git history so if async spawning ends up not
> working for many people we can always put it back later.
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>