Enable Build With Visual Studio #35
Conversation
Visual Studio does not like function declarations to be marked with __declspec (dllexport) without the prototypes being marked likewise, so add the EPOXY_IMPORTEXPORT annoation to the prototypes in the public headers, so that things can build under Visual Studio as well.
This adds C99 headers stdint.h, inttypes.h and stdbool.h that are not available on Visual Studio 2012 and earlier, so that they can be referred to during the build of libepoxy (and possibly the use of it). The stdint.h and inttypes.h implementation are taken from the msinttypes project[1], and the stdbool.h is adapted from the one from gnulib. [1]: https://code.google.com/p/msinttypes/
As this code is obviously not only built on gcc, define a constructor that is suitable for use on Visual Studio, in addition to the current gcc one. Also, avoid defining an empty struct (which is not allowed on any MSVC), and make sure that we have GLAPIENTRY (i.e. __stdcall) just before the parameter part of the function declaration/prototype, as that is where Visual Studio expects them to be, and is also accepted on gcc. As epoxy_conservative_gl_version() is marked for export in dispatch_common.c, do likewise for distpatch_common.h by using PUBLIC, as Visual Studio does not like export annotations to be done on function declarations but not the prototypes.
Update the Python code generating script by: -Generating the arrays of providers and enumeration in a way that is understood by C89 compilers. Might not be the most robust way for this, but anyways... as the providers retrieved in order from the various XMLs. -Use __declspec(noinline) in place of the gcc-specific __attribute__((noinline)) on Visual Studio builds. -Generate the resolver table struct in a way that is acceptable by C89 compilers, like pre-2013 MSVC.
This moves the source, headers and test program listings from the respective Makefile.am's under src/ and test/ to their respective Makefile.sources. This is done so that we can have NMake Makefiles later that can also refer to the same Makefile.sources to build the libepoxy DLL and the relevant test programs. src/Makefile.am has also been re-organized a bit so that we can ensure that the non-generated sources and headers are distributed and built, but then that the generated ones are not distributed.
Ensure that we have __stdcall only just before the parameters part of a function declaration or prototype, as this is what Visual Studio expects, and is also accepted by gcc.
This adds NMake Makefiles that can be used to build the libepoxy DLL (with WGL support), and the test programs that are relevant to the WGL "backend", and adds the NMake Makefiles and the C99-compatibility headers needed for pre-2013 MSVC versions to the distributions. This NMake Makefile set supports Visual Studio 2008 through 2013. Like the earlier patch on the Makefile.am's, these NMake Makefiles also consume the Makefile.sources to identify the sources needed for the build.
|
Alternatively, I'd really like to see an MSVC 2013-only port. I'm really uncomfortable with putting all of this stuff in (particularly the headers with the many different licenses) just to deal with a stale compiler. |
|
Hello Eric, I see, but then the main reason for this is because we would like to have support for at least Visual Studio 2010 (and Visual Studio 2008, which I believe is more or less the same situation with Visual Studio 2010, except that it does not ship with stdint.h), which many people that are using and building GTK+ are still using, which is the main driving force behind this. Perhaps it would be better if I have people load their own stdint.h and/or inttypes.h and/or stdbool.h, which I think is part of your concerns, instead of bundling them with the sources? I will do the updates for this part in a bit, and let people know that they need to do so. Unfortunately this is unlike the xz-utils case where its public headers are still usable from older compilers, even when the sources are C99, as the libepoxy public headers (in particularl the generated ones), have to be updated as well to be usable in older compilers, as the scripts generate both the sources and headers. With blessings, thank you! |
|
Hello Eric, I just saw your reply in issue #34 that two fewer tests were passing. Are they in the tests/? Somehow I didn't realize them, as I tried "make distcheck" on my Fedora system, and all was well. I will update the MSVC NMake Makefiles to make sure that they have license comments later on today though. With blessings, thank you! |
Instead, update the NMake Makefiles and tell people in there that they will need to go and acquire their own stdint.h, inttypes.h and stdbool.h to be used for building and using libepoxy. Also update the CFLAGS a bit, as they can be grouped together, to make things neater. Also add the copyright notice in msvc/detectenv-msvc.mak.
Apaprently the definition of the macros were a bit wrong, fix them.
|
Hello Eric, I removed the headers that are used for C99 compatibility, and instead have the people that will build and use libepoxy acquire them instead, as they are not that hard to find. About making the rest compatible with only MSVC 2013+, it does seem to me only the Python script can be changed from this point from my patchset, if we really want to go that route. All the other patches are all still needed for MSVC 2013 (obviously sans the addition of C99-compatibility headers, which I dropped), and even so, it does seem that the update required for the Python script is also largely needed, via some simple tests here using MSVC 2013 with all the latest updates. The differences in the changes in the Python scripts for pre-MSVC 2013 builds and for MSVC 2013+ builds are actually quite small, compared to the other required changes, and I think it would still be best to keep the public headers usable by older, non-GCC compilers as well, like what xz-utils does, at least on Windows. Even in MSVC 2013 and later, I don't think having empty structs is a notion that would ever be accepted there. With blessings, thank you! |
|
@fanc999 I guess if we want to go further on this would be better to split this in 2 issues. First get a patch that adds support for msvc 13 and then think about the backward compatibility things. Any chance you could do this? |
|
Hi @nacho, I will look into splitting this up, as you mentioned. However, I won't be able to do so until next week as I would be away on a family trip for a vacation. Thanks for the tip-I think it would make it more apparent that the code changes required for MSVC 2013+ is only just a teeny-meeny little bit less for earlier Visual Studio versions, due to syntactical requirements and the use of GCC-specific items in the current code. With blessings, thank you! |
|
Hi @nacho, I think I am finally ready to split this pull request up, so I got rid of my fork and re-started this whole thing. So, I think it is better that I close this pull request and start a new one for MSVC 2013 and another for earlier MSVC versions. For references, they are done as follows: With blessings, thank you! |
Hi,
I thought it might be easier for you to review the patches that are done in the github workflow, so here they are.
Please see issue #34 for details about these.
With blessings, thank you!