GNOME Bugzilla – Bug 758759
Add Visual Studio build support
Last modified: 2016-03-15 11:08:18 UTC
Hi, As we are seeking for better Windows support in our (portable parts of the) platform and more input from people that are interested in making things work better for Windows, this bug report is opened for adding Visual Studio build support for libsoup. The other motivations that are behind this are -There is ongoing work to have OpenSSL as a supported backend for glib-networking. -The codebase of libsoup is largely ready for build under Visual Studio already. I will attach patches for adding this support shortly. In this drive, many, many thanks need to go to Ignacio Casel Quinteiro, for: -Getting the OpenSSL backend for glib-networking written and work. -Making libsoup more ready for non-GCC builds. With blessings, thank you!
Created attachment 316420 [details] [review] examples/simple-httpd.c: Make code more portable Hi, First up is the updates to examples/simple-httpd.c, as it uses some POSIX APIs for working with files. This patch moves those API calls to GLib ones, so that the code will build out-of-the-box on MSVC and work better on Windows...
Created attachment 316421 [details] [review] build: Add a Python utility script for replacing strings in files Hi, This adds a simple utility Python script that can be used during the build to replace items, notably in libsoup/soup-version.h.in, so that we can obtain libsoup/soup-version.h with the proper info in there. This is done also because Python is already needed during the build for tld_data.inc. Please let me know if dist'ing the generated libsoup/soup-version.h is preferred instead, as this will be called within the projects using property sheets, which will have the version info put in there during configure.
Created attachment 316422 [details] [review] build: Add a pre-configured config.h(.win32.in) template Hi, This adds a pre-configured config.h template that would be used by Visual Studio builds, since we won't be using autotools during Visual Studio builds...
Created attachment 316423 [details] [review] build: Add common autotools modules for generating Visual Studio projects from templates Hi, This adds two autotools modules, that is copied directly from $(GLib_srcroot)/build, which are used to: -Generate the MSVC 2008/2010 full projects for libsoup and libsoup-gnome from their respective templates, as well as the property sheets to "install" libsoup, with the latest source and public header listings. -Copy the MSVC 2010 project files and update items so that we can support MSVC 2012, 2013 and 2015 out-of-the-box...
Created attachment 316424 [details] [review] build: Add Visual Studio Projects Hi, Here is one part of the core, main items :), the Visual Studio 2008-2015 projects that are used to build libsoup, libsoup-gnome and the example programs. As noted in the previous comment, the full projects for libsoup and libsoup-gnome are generated during 'make dist', as well as the property sheets that is used to "install" libsoup. Note again that the Visual Studio 2012-2015 projects are generated during 'make dist' as they are copied from the Visual Studio 2010 ones and updated accordingly...
Created attachment 316425 [details] [review] build: Add common autotools modules for generating commands and items for introspection under NMake Hi, --- Sorry, I forgot to mention that attachment 316424 [details] [review] may need to be applied with --ignore-whitespace, as the .sln files must use Windows/DOS line feeds. --- This patch adds an autotools module, copied from $(gi_srcroot)/build that is used to generate the full command lines for g-ir-scanner and g-ir-compiler for use under Visual Studio's NMake, so that we can build the introspection files under Visual Studio builds...
Created attachment 316426 [details] [review] build: Support introspection for Visual Studio builds Hi, This makes use of the previous patch (attachment 316425 [details] [review]) to generate the full commands for g-ir-scanner and g-ir-compiler during 'make dist', so that we can build the introspection files for libsoup and libsoup-gnome using NMake. These patches are what I have to support builds of libsoup under Visual Studio, with support for building introspection. With blessings, thank you!
Hey Dan, I think we should get this in. Apart from the test changes (which I already reviewed before putting the patch here in the bug report), the rest of the changes are visual studio specific and Fan is our expert on it.
Comment on attachment 316420 [details] [review] examples/simple-httpd.c: Make code more portable >+ while ((dir_name = g_dir_read_name (dir))) { "file_name" or just "name" would be a better variable name here > index_path = g_strdup_printf ("%s/index.html", path); >- if (stat (index_path, &st) != -1) { >+ if (g_stat (path, &st) == -1) { Two mistakes there (path vs index_path, == vs !=)
Comment on attachment 316421 [details] [review] build: Add a Python utility script for replacing strings in files >+# This can be used in various projects where >+# there is the need to replace strings in files, >+# and is copied from GLib's $(srcroot)/build/win32 Ideally this would be installed somewhere ("gnome-win32-build-tools" or something) rather than being copy+pasted
Comment on attachment 316423 [details] [review] build: Add common autotools modules for generating Visual Studio projects from templates > build/Makefile-newvs.am | 45 ++++++++++++++++++++ > build/Makefile.msvcproj | 107 ++++++++++++++++++++++++++++++++++++++++++++++++ Why are these in build/ rather than build/win32? (Though really, if everything is going to be under build/win32, then it's silly to have two levels of directories, and it should be "build-win32" or something instead.)
Comment on attachment 316424 [details] [review] build: Add Visual Studio Projects >+dist-hook: \ >+ $(top_builddir)/build/win32/vs9/soup.vcproj \ >+ $(top_builddir)/build/win32/vs9/soup.headers \ >+ $(top_builddir)/build/win32/vs9/soup-gnome.vcproj \ >+ $(top_builddir)/build/win32/vs9/soup-gnome.headers This seems wrong; you're making "make dist" depend on the existence of some files in another directory, but not actually doing anything with them other than requiring them to exist (in the build tree, not the dist tree).
Comment on attachment 316425 [details] [review] build: Add common autotools modules for generating commands and items for introspection under NMake as above, why build/ rather than build/win32
Hi Dan, (In reply to Dan Winship from comment #11/#13) > Why are these in build/ rather than build/win32? Initially this was done this way in GLib, GTK+ etc., as I thought that since these were autotools scripts that would be included by various Makefile.am's to create the full projects from them, so I thought they ought to be under build/, not build/win32. > (Though really, if everything is going to be under build/win32, then it's > silly to have two levels of directories, and it should be "build-win32" or > something instead.) I agree with you, though in the case in GLib, Pango and GTK+, before I took over maintaining the Visual Studio projects from Tor, build/win32/vsX was where the Visual Studio projects resided, so doing them here in build/win32 was following that. We could move everything in $(srcroot)/build/win32 to something like $(srcroot)/win32 or $(srcroot)/msvc or so (such as in the case of GStreamer), if that is okay with the other maintainers of the projects, as probably it will be best to do that as well for the other projects (that includes GLib, G-I, Pango, ATK, GDK-Pixbuf, GSettings-Desktop-Schemas, GTK+, JSON-GLib, Cogl, Clutter, GTKSourceView, if I didn't miss anything from the list), if that is preferred. p.s. In the case of GLib, JSON-GLib, Cogl and Clutter, there were also other files used in (other) builds as well, so these would probably be best to be left alone, and this is another reason why build/win32 was initially chosen. (In reply to Dan Winship from comment #12) > This seems wrong; you're making "make dist" depend on the existence of some > files in another directory, but not actually doing anything with them other > than requiring them to exist (in the build tree, not the dist tree). What happens is this: the items generated by 'dist-hook:' in libsoup/Makefile.am are actually consumed by build/win32/vs9/Makefile.am and build/win32/vs10, where build/win32/vs9/*.vcproj (and so build/win32/vs10/*.vcxproj and build/win32/vs10/*.vcxproj.filters) are actually dist'ed and the .headers are further processed in these Makefile.am's to create the full property sheets (soup-install.[props|vsprops]), which will also then be disted. Hence in $(srcroot)/Makefile.am, build comes after libsoup in the SUBDIRS. Hope this explains the situation clearer. With blessings, thank you!
(In reply to Fan, Chun-wei from comment #14) > > Why are these in build/ rather than build/win32? > > Initially this was done this way in GLib, GTK+ etc. > We could move everything in $(srcroot)/build/win32 to something like > $(srcroot)/win32 or $(srcroot)/msvc or so (such as in the case of > GStreamer), if that is okay with the other maintainers of the projects OK, I guess for now use the same layout as GLib, etc, and if you end up changing those later, change libsoup as well. > (In reply to Dan Winship from comment #12) > > This seems wrong; you're making "make dist" depend on the existence of some > > files in another directory, but not actually doing anything with them other > > than requiring them to exist (in the build tree, not the dist tree). > > What happens is this: the items generated by 'dist-hook:' in > libsoup/Makefile.am are actually consumed by build/win32/vs9/Makefile.am... so why not put them as dependencies there? It doesn't seem to make sense to mention them in libsoup/Makefile.am
Hello Dan, (In reply to Dan Winship from comment #15) > > What happens is this: the items generated by 'dist-hook:' in > > libsoup/Makefile.am are actually consumed by build/win32/vs9/Makefile.am... > > so why not put them as dependencies there? It doesn't seem to make sense to > mention them in libsoup/Makefile.am Hmm, I am not that much of an autotools expert but I will try to explain the situation and rationale here, any suggestions, if any, to do this in a better way would be appreciated. The reason is that when 'make dist' happens, it actually reads from the list of sources and headers from libsoup/Makefile.am, so that they will be consolidated into a series of list files, and so this is why this is not done in build/win32/vs9/Makefile.am and build/win32/vs10/Makefile.am This is where build/Makefile.msvcproj comes in, as it is included here, as it actually wraps what was done initially by Tor, in GLib, for example, to create the full Visual Studio projects, so that we do not add too much clutter in the various Makefile.am's. It was done this way so that we reduce the maintenance burden whenever sources and public headers are added/removed, so that projects that use this mechanism will contain the proper list of sources and headers during 'make dist'. To illustrate, this is briefly what happens in build/Makefile.msvcproj during 'make dist', for the libsoup DLL: 1) build/win32/vs9/soup.sourcefiles, build/win32/vs10/soup.vs10.sourcefiles and build/win32/vs10/soup.vs10.sourcefiles.filters, which consists of the list of source files to build in the format of Visual Studio 2008/2010 projects, repsectively, are first generated by reading from $(soup_FILES), which is set as $(libsoup_2_4_la_SOURCES). No source files, such as UNIX-specific sources, are excluded in our case here, so $(soup_EXCLUDES) is set as dummy. 2) build/win32/vs9/soup.sourcefiles, build/win32/vs10/soup.vs10.sourcefiles and build/win32/vs10/soup.vs10.sourcefiles.filters are then run through the C preprocessor on build/win32/vs9/soup.vcprojin, build/win32/vs10/soup.vcxprojin and build/win32/vs10/soup.vcxproj.filtersin so that we get the full build/win32/vs9/soup.vcproj, build/win32/vs10/soup.vcxproj and build/win32/vs10/soup.vcxproj.filters. Note that build/win32/vs10/soup.vcxproj and build/win32/vs10/soup.vcxproj.filters are generated alongside with build/win32/vs9/soup.vcproj, in build/Makefile.msvcproj. Note also that (1) and (2) take place all within build/Makefile.msvcproj. 3) Likewise, for build/win32/vs9/soup.headers (and therefore build/win32/vs10/soup.vs10.headers, as build/Makefile.msvcproj directs), is generated from reading $(soup_HEADERS_DIR), set as $(libsoupincludedir) and reading $(soup_HEADERS_INST), set as $(libsoupinclude_HEADERS) $(nodist_libsoupinclude_HEADERS), to contain the full listing of headers to copy with their copy destinations, in a way that is understood by Visual Studio 2008/2010 repectively. No header files are excluded in our case here, likewise, so $(soup_HEADERS_EXCLUDES) is also set as dummy. Unlike (1) and (2), build/win32/vs9/soup.headers and build/win32/vs10/soup.vs10.headers are first placed in build/win32/vs9/ and build/win32/vs10/, as there may be more build/win32/vs9/*.headers and build/win32/vs10/*.vs10.headers, which is soup-gnome in our situation here. Note that since some projects may not install headers, if the $(ProjectName).headers is not specified within 'dist-hook:' 4) When the build process gets into to build/win32/vs9/ and build/win32/vs10/, the full build/win32/vs[9|10]/soup-install.[vsprops|props] is generated by running all the build/win32/vs9/*.headers and build/win32/vs10/*.vs10.headers through the C processor on build/win32/vs[9|10]/soup-install.[vspropsin|propsin], and the build/win32/vs9/*.headers and build/win32/vs10/*.vs10.headers are removed upon completion. Sorry for this longish reply, but hopefully this will explain the situation better. With blessings, thank you!
Created attachment 318838 [details] [review] examples/simple-httpd.c: Make code more portable (take ii) Hi Dan, Here goes the fixed simple-http.c... With blessings, thank you!
(In reply to Fan, Chun-wei from comment #17) > Created attachment 318838 [details] [review] [review] > examples/simple-httpd.c: Make code more portable (take ii) > > Hi Dan, > > Here goes the fixed simple-http.c... > > With blessings, thank you! Hey Fan, wrong patch?
Created attachment 321645 [details] [review] examples/simple-httpd.c: Make code more portable (take ii) Hi Nacho, Sorry, for forgetting to re-upload the patch... oops, and thanks!
Comment on attachment 321645 [details] [review] examples/simple-httpd.c: Make code more portable (take ii) >@@ -96,7 +96,7 @@ do_get (SoupServer *server, SoupMessage *msg, const char *path) > } > > index_path = g_strdup_printf ("%s/index.html", path); >- if (stat (index_path, &st) != -1) { >+ if (g_stat (path, &st) == -1) { still one != vs == bug otherwise good to commit
Comment on attachment 321645 [details] [review] examples/simple-httpd.c: Make code more portable (take ii) actually: ../../../examples/simple-httpd.c:37:18: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] while ((d_name = g_dir_read_name (dir))) {
Created attachment 321807 [details] [review] examples/simple-httpd.c: Make code more portable (take iii) Hello Dan, Thanks for the reviews, I will get the Visual Studio build files in first. (In reply to Dan Winship from comment #20) > > still one != vs == bug Hmm, I missed that... Fixed now. > ../../../examples/simple-httpd.c:37:18: warning: assignment discards ‘const’ > qualifier from pointer target type [-Wdiscarded-qualifiers] > while ((d_name = g_dir_read_name (dir))) { Got rid of the warning, via casting. So here's the new patch. With blessings, thank you!
Review of attachment 321807 [details] [review]: Fan, see my comment inline. ::: examples/simple-httpd.c @@ +36,2 @@ if (dir) { + while ((d_name = (gchar *)g_dir_read_name (dir))) { Fan I think you should instead change the declaration of d_name to const gchar *d_name
Hi, For records, the patches were pushed as follows: Attachment 316421 [details]: d80106d Attachment 316422 [details]: 81a46b6 Attachment 316423 [details]: cd44172 Attachment 316424 [details]: cd897e4 Attachment 316425 [details]: 4bebae9 Attachment 316426 [details]: 46d83dc With blessings, thank you!
Created attachment 321812 [details] [review] examples/simple-httpd.c: Make code more portable (take iii.5) Hi Nacho, Here we go...
Created attachment 321813 [details] [review] examples/simple-httpd.c: Make code more portable (take iii.5) Hi Nacho, (Sorry, wrong patch version, D'OH!) Re-doing upload, should fix the thing. With blessings, thank you!
Hi Dan, Thanks for the ACK, the patch (attachment 321813 [details] [review]) was pushed as 53a3dd2. I will close this bug shortly. p.s. I saw MIT Kerberos GSSAPI support that was just added, any calls or demands for me to add building with GSSAPI support to the projects? With blessings, thank you!
(In reply to Fan, Chun-wei from comment #27) > p.s. I saw MIT Kerberos GSSAPI support that was just added, any calls or > demands for me to add building with GSSAPI support to the projects? evolution is going to start making use of it soon