Re: [anjuta-devel] Port to Windows

[Johannes Schmid <jhs jsschmid de>]

Hi!

> 1. Getting the paths in Windows. Programs in Windows needs to be 
> relocatable, so paths should be calculated at runtime. This could be 
> fixed this way:
>
> - Provide some functions that create the paths at runtime. This is what 
> GTK+ uses, though the functions are private since it's used only inside 
> the GTK+ libraries. They are in gtk/gtkwin32.c in the sources. These 
> functions create the paths then store them into static variables so that

> they could return "const gchar *". Seems like those paths are not freed 
> at all. Glade also do something like this in gladeui/glade-app.c, though

> GladeApp is a singleton and free the variable when it is freed.
>
> - Per plugin paths are created with functions that return strings that 
> should be freed. Something like "gchar *anjuta_plugin_get_data_dir 
> (const gchar *plugin_name);". The question now would be when they should

> be created and freed (probably in activation and deactivation). This 
> will also need some changes to the Makefile's to remove the macros for 
> paths.

static const gchar*
anjuta_plugin_get_data_dir (AnjutaPlugin' plugin)

It should be freed when the plugin is destroyed. Actually we could just
replace the current #defines by a call to that function to make it easier
to port. But in *nix this function should use the paths as given by the
current Makefile.am while it may use something else on win32 (maybe
https://developer.gnome.org/glib/2.35/glib-Windows-Compatibility-Functions.html).
  
> - fcntl is not available in Windows. Also, pipes cannot be non-blocking,


Really? The documentation about g_spawn_async doesn't say anything about
blocking on Windows and GIOChannel does neither (apart from that GLib
implemenets a thread to support async reading).
 
> - Signals are not available in Windows. We could emulate SIGKILL and 
> SIGTERM by forcibly killing a process using TerminateProcess, which will

> not kill it's child processes. Is this the expected result? Are there 
> any differences between SIGKILL and SIGTERM, anyway? Also we could not 
> tell if a process was forcibly killed or it exited normally since the 
> autotools plugin checks the signals so that it will know how the build 
> was cancelled, though we may assign some special exit codes when we call

> TerminateProcess.

Probably the best sulution. There is a difference between SIGKILL and
SIGTERM (see man kill) but it probably doesn't matter here too much. It
would be clever to assign an exit code if we killed the process though.
 
> - Shell scripts. Windows do not support shell scripts, and g_spawn_* 
> will not be able to find them (since they are not recognized as 
> executable by Windows). I created a program to fake scripts temporarily;

> it will look for the scripts in PATH then check the shebang to know what

> interpreter to spawn. This also means we would depend to sh or bash (not

> sure if bash is available in Windows) to run scripts like autogen.sh, 
> configure, autoconf and automake. I might merge the code of this program

> later to AnjutaLauncher.

Looks good in general. Isn't there a generic sultion to that problem on
windows?
 
> - Add application/x-ext-* to each real mime type in each plugins. For 
> example change the MimeTypes value of the plugin file of 
> language-support-vala from "text/x-vala" to 
> "text/x-vala;application/x-ext-vala;application/x-ext-vapi". 
> g_content_type_* will still not work.

I would do this but probably add an extra line for WindowMimeTypes=...
because it might get messy otherwise.
 
Regards,
Johannes