|
Hello, I just want to let everyone else know about the current status of the port to Windows. It is still far from finished. I also want to know what others think about the solutions possible to fix the build. Things to be fixed: 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. In what GObject should we put them? Should they be static or do they need an instance of that object? 2. forkpty and AnjutaLauncher. I tried porting them to Windows to use g_spawn_async_with_pipes but the following problems arose: - forkpty is not available in Windows. - fcntl is not available in Windows. Also, pipes cannot be non-blocking, and I wasn't able to find any solution to this problem yet. I haven't tried it yet to a real Windows (because of #1), but it hangs for some seconds when pkg-config is being called. It will freeze when anjuta-tags is called. We cannot turn off buffering, I tried using g_io_channel_set_buffered but it also requires the encoding to be set to NULL. - (Related to fcntl) We could only get standard input and standard output from g_spawn_async_with_pipes separated. Standard input with standard input combined is used by Anjuta to detect when the terminal is asking for passwords. Enabling the echoing of the output to the input is how it is done in forkpty, using fcntl. Check out anjuta_launcher_scan_pty for more info. - 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. - 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. 3. Mime types. Windows only support a small subset of mime types in its registry by default. File types not in the registry have mime type as "application/x-ext-*", where * is the file extension. Programs in Windows could install their file types (including mime types) during installation, but it will require the program to be installed by an installer. It is also quite messy, some programs might have already installed some file types (i.e. Visual Studio) then Anjuta might overwrite them. Uninstalling Anjuta might leave those programs broken. So possible solutions: - The installer will install the necessary file types and mime types. This will require Anjuta to be installed using an installer, and the installer will need some sort of code to properly set and unset them. But it will have the most complete support for mime types. - Change anjuta_util_get_file_mime_type to detect mime type. For example, when GLib says that the content type id is "application/x-ext-vala", return "text/x-vala" instead. g_content_type_* will not work properly though (used for example to detect if text/x-csrc is also a text/plain), since they are not in the registry. - 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. 4. Installers. We could probably use https://live.gnome.org/msitools which is compatible to Wix. Current patches, scripts and binaries to cross-compile Anjuta: http://ubuntuone.com/5lUbY7YCIkaZWHt6ofJnKB Regards, Arnel |