GNOME Bugzilla – Bug 688611
Add support for compiling for Windows platforms in some templates
Last modified: 2020-11-06 20:21:38 UTC
Created attachment 229326 [details] [review] Initial version of the patch to add Windows support Some additional changes to configure.ac and Makefile.am in the templates are necessary for the resulting projects to be compiled correctly in Windows platforms.
Seems like there are some additional changes necessary to support Windows; applications should be relocatable, so g_win32_get_package_installation_directory_of_module should be called instead of using the macro PACKAGE_DATA_DIR when looking for data files such as GtkBuilder UI files. Or use GResource that is compiled into an object and linked to the application. I decided to add support to some of the templates instead of creating a new one. Should I create a new project option in the project wizard for supporting Windows?
I think we can add another configuration in the anjuta.session file used by these templates to compile for windows by example: [Build] Configuration list=1:Default:%%%1:Debug:Debug%%%1:Profiling:Profiling%%%1:Optimized:Optimized%%%1:Windows Selected Configuration=Debug BuildArgs/Default=--enable-maintainer-mode BuildArgs/Debug=--enable-maintainer-mode 'CFLAGS=-g -O0' 'CXXFLAGS=-g -O0' 'JFLAGS=-g -O0' 'FFLAGS=-g -O0' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig' BuildArgs/Profiling=--enable-maintainer-mode 'CFLAGS=-g -pg' 'CXXFLAGS=-g -pg' 'JFLAGS=-g -pg' 'FFLAGS=-g -pg' BuildArgs/Optimized=--enable-maintainer-mode 'CFLAGS=-O2' 'CXXFLAGS=-O2' 'JFLAGS=-O2' 'FFLAGS=-O2' BuildArgs/Windows=--host=mingw I think this doesn't need any change in the C code. I think we can use g_win32_get_package_installation_directory_of_module instead of PACKAGE_DATA_DIR by checking something defined in the config.h file. If it's not existing we can even add one. But this option is not obvious. I'm afraid it will be difficult to find for a new user. So I think it's useful to add a template specifically for windows, providing a Default and a Debug configuration and perhaps some variant using cygwin instead of mingw by example.
Created attachment 241084 [details] [review] Updated patch for Windows support Added Windows support option in some wizards. Windows support is added only if enabled. Disabled by default. Will no longer remove -Wl,--export-dynamic, but replace it with -Wl,--export-all-symbols when compiling for Windows. Added AC_CANONICAL_HOST in configure.ac, to make sure the host is computed. Sample GTK+ source file with Windows support. I will update the GTK+ Application and Vala GTK+ source files if you think this one is good enough. There are differences though, there should be a '#define TEST' in the source so that the UI file in the source directory will be used. Should I add the code to get prefix, datadir, etc. even if it will not be used? I think its better if they are there, so that the user could use them.
Created attachment 241085 [details] [review] Initial patch for default Windows configuration I used the defaults used by Ubuntu, Fedora and OpenSUSE so that users of https://build.opensuse.org/project/show?project=windows:mingw:win32 in OpenSUSE and Fedora could use them. The default is for 32-bit, should I add configuration for 64-bit? Should I add Debug, Profiling and Optimized too? Though they would make the list quite long.
Review of attachment 241084 [details] [review]: Thanks for your patch, it is really good but I have a few questions. I think the following check in configure.ac: case $host_os in *mingw* | pw32* | *cygwin*) platform_win32=yes ;; *) platform_win32=no ;; esac AM_CONDITIONAL(PLATFORM_WIN32, test x"$platform_win32" = "xyes") case $host_os in *mingw*) native_win32=yes ;; *) native_win32=no ;; esac AM_CONDITIONAL(NATIVE_WIN32, test x"$native_win32" = "xyes") will be a bit better like this case $host_os in *mingw*) platform_win32=yes native_win32=yes ;; pw32* | *cygwin*) platform_win32=yes native_win32=no ;; *) platform_win32=no native_win32=no ;; esac AM_CONDITIONAL(PLATFORM_WIN32, test x"$platform_win32" = "xyes") AM_CONDITIONAL(NATIVE_WIN32, test x"$native_win32" = "xyes") What do you think? Then, I think your "#define TEST" in the C source files, allowing to use data from the source directory instead of the installation directory is better than our current option which is to put a line in comment. I think this is really an issue for a newcomer so perhaps it will be even better to handle this at run time: check first into a directory related to the current program directory ../data by examples and if not found search in the normal installation directory. What do you think? I think it can be a bit annoying for a released program to work like this as it will be unexpected for Linux so I'm really not sure it's better. So your solution is perhaps better and another work around could be to use GResource. A last possibility can be to define TEST through the command line only in debug configuration. What is the code to get prefix, datadir and so on? Is it some code in configure.ac or in Makefile or is it in the C files? Anyway, if you think it's better, I think you can add it.
Created attachment 241112 [details] [review] Updated patch for Windows support (updated platform/native Windows check) (In reply to comment #5) > Review of attachment 241084 [details] [review]: > > Thanks for your patch, it is really good but I have a few questions. > > I think the following check in configure.ac: > case $host_os in > *mingw* | pw32* | *cygwin*) > platform_win32=yes > ;; > *) > platform_win32=no > ;; > esac > AM_CONDITIONAL(PLATFORM_WIN32, test x"$platform_win32" = "xyes") > case $host_os in > *mingw*) > native_win32=yes > ;; > *) > native_win32=no > ;; > esac > AM_CONDITIONAL(NATIVE_WIN32, test x"$native_win32" = "xyes") > will be a bit better like this > case $host_os in > *mingw*) > platform_win32=yes > native_win32=yes > ;; > pw32* | *cygwin*) > platform_win32=yes > native_win32=no > ;; > *) > platform_win32=no > native_win32=no > ;; > esac > AM_CONDITIONAL(PLATFORM_WIN32, test x"$platform_win32" = "xyes") > AM_CONDITIONAL(NATIVE_WIN32, test x"$native_win32" = "xyes") > What do you think? Okay, I also think it's better. I just copied it from Glade. (Attached patch) > Then, I think your "#define TEST" in the C source files, allowing to use data > from the source directory instead of the installation directory is better than > our current option which is to put a line in comment. > > I think this is really an issue for a newcomer so perhaps it will be even > better to handle this at run time: check first into a directory related to the > current program directory ../data by examples and if not found search in the > normal installation directory. What do you think? > I think it can be a bit annoying for a released program to work like this as it > will be unexpected for Linux so I'm really not sure it's better. So your > solution is perhaps better and another work around could be to use GResource. A > last possibility can be to define TEST through the command line only in debug > configuration. Actually, that's a bit near how GTK+ does it: it checks if the last part of its location has ".libs", if it doesn't it will assume it is installed. The problem is that it only works in Windows because it has the g_win32_get_package_installation_directory_of_module function. In Linux, GTK+ just uses PACKAGE_DATA_DIR, etc. But I don't know if checking the existence of files first is good, maybe we should ask the other developers of Anjuta. We could also create a variable in configure, like "TEST", then the Makefile.am will add additional command arguments to the preprocessor (AM_CPPFLAGS), like "-DTEST", so that the sources could use "#ifdef TEST" to know if it is compiled for testing. We need to add a new option in configure though. Or add it directly to config.h, though I don't know how to do that. I think we should decide first if Debug-configured projects should be installable. If it is, decide whether to directly add the tests inside the sources or let the user #define something (current way). If they shouldn't be installed, find a way to let the sources know it is configured for debugging. > What is the code to get prefix, datadir and so on? Is it some code in > configure.ac or in Makefile or is it in the C files? Anyway, if you think it's > better, I think you can add it. They are in the main() function of the file templates/gtk/src/main.c.
Review of attachment 241085 [details] [review]: Thank you for your patch but I have rewritten it to add the new configuration in the project wizard templates. Note, that I have not been able to fully check the cross compilation for Windows because I haven't gtk3 installed on my system.
Review of attachment 241112 [details] [review]: Thanks for this patch. I have committed it with some small changes to use the TEST define even if Windows support is not enabled. Just tell me if you think it's not right. One small detail, you can discard the end of line after an autogen macro by ending it with "\+]" instead of "+]", this is useful to write them on their own line. Then, I think it's fine like this. Do you want to add Windows support to more templates?
(In reply to comment #8) > Review of attachment 241112 [details] [review]: > > Thanks for this patch. I have committed it with some small changes to use the > TEST define even if Windows support is not enabled. Just tell me if you think > it's not right. I think it's much better. > One small detail, you can discard the end of line after an autogen macro by > ending it with "\+]" instead of "+]", this is useful to write them on their own > line. Thanks, don't know about that. > Then, I think it's fine like this. Do you want to add Windows support to more > templates? I'm planning to add the code for getting the paths at runtime to the main C and Vala sources of gtkmm, gtkapplication and vala-gtk templates.
(In reply to comment #9) > I'm planning to add the code for getting the paths at runtime to the main C and > Vala sources of gtkmm, gtkapplication and vala-gtk templates. Ok, thanks again for your work. I keep this bug open, so you can attach your patches here.
Created attachment 242263 [details] [review] Patch to further minimize use of preprocessor directives
Created attachment 242264 [details] [review] gtkapplication
Created attachment 242265 [details] [review] gtkmm
Created attachment 242266 [details] [review] vala-gtk This is how I add Windows support to my Vala projects. Using preprocessors in Vala means that the user who would compile the sources needs to regenerate the C sources since they are platform-specific. Vala doesn't support C preprocessor directives. Using if {} else {} won't work either, since Windows compatibility functions are not defined at all in Unix.
Created attachment 242267 [details] Add session file for vala-gtk Adding the session file was disabled by commit d67b00a21d479d82a6981562af30edcb03806597 because VPATH is broken on Vala projects. I'm not sure it it still doesn't work, though I use it in my projects (the older Vala compilers definitely prevents me from building in a different directory than the source directory). I could now compile in a VPATH but adding new files sometimes fails and I have to remove the generated C sources to force regeneration. And I haven't touched those projects myself for some months so I can no longer remember if I got other problems related to it. So I'm not sure if this should be committed at all.
I only tested these by trying to compile with Windows support and without, then defining TEST and commenting it out. I tested using openSUSE 12.3 with obs://windows:mingw:win32 repo (which could be added too in Fedora, or manually installed in Ubuntu). To test them, install wine and: gtk and gtkapplication: mingw32-cross-gcc mingw32-gtk3 mingw32-gtk3-devel gtkmm: mingw32-cross-gcc-c++ mingw32-gtkmm3 mingw32-gtkmm3-devel vala-gtk: valac mingw32-cross-gcc mingw32-gtk3 mingw32-gtk3-devel Maybe we should add these to the documentation? Also, I think the plugin for running executables should automatically detect/append executable names with '.exe' extension. So that the user could just click run instead of fiddling with the run dialog and adding '.exe' to the executable name before running it.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/anjuta/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.