And so remove the current year to ease maintenance and since it is not
strictly necessary.
Also remove individual copyright holders (where appropriate) and replace
the name with "The Geany contributors". The detailed authorship
information is still available in the GIT history.
Also remove copyright notice and author names from READMEs.
Hide spawn_get_program_name(), spawn_async_with_pipes() and
spawn_get_exit_status_cb(), which are not used by anyone else and
should not be part of the plugin API unless explicitly required.
See http://lists.geany.org/pipermail/devel/2015-June/thread.html#9521
Note: this duplicates some documentation when a now hidden function was
referred to.
When passed Foo Bar Qux as a command line, Windows will try to run
Foo.exe Bar Qux, then "Foo Bar.exe" Qux, and last "Foo Bar Qux.exe",
for maximum flexibility. Quoting Foo supresses this behaviour.
g_spawn_async_with_pipes() under Windows has various drawbacks:
- There is no g_shell_parse_argv() for windows. It's not hard to write
one, but the command line recreated by mscvrt may be wrong.
- GLib converts the argument vector to UNICODE. For non-UTF8 arguments,
the result is often "Invalid string in argument vector at %d: %s:
Invalid byte sequence in conversion input" (YMMV). Our tools (make,
grep, gcc, ...) are "ANSI", so converting to UNICODE and then back
only causes problems.
- For various reasons, GLib uses an intermediate program to start
children (see gspawn-win32.c), with the side effect that the
grandchildren output (such as make -> gcc) is not captured.
- With non-blocking pipes, the g_io_add_watch() callbacks are never
invoked, while with blocking pipes, g_io_channel_read_line() blocks.
- Some smaller problems, explained in spawn.c as inline comments.
The spawn module tries to fix these problems, and to provide easier
APIs, which guarantee that the callbacks will synchronized as expected,
and g_io_channel_read_line() will not be required, since even under
Unix, it may buffer lines of unlimited length.
This initial commit only adds the module source and header files, and
includes it in the various build systems.
You can see PR 274 for a long discussion about the module.
