[polygon] Compiling polygon under Windows
Hello, I have been compiling boost::polygon under Windows (VS2008, MSVC9.0 specifically) and have run into a minor problem with boost::polygon's detection of Microsoft's compiler. Specifically, it tests for the WIN32 preprocessor define instead of _WIN32. WIN32 isn't actually defined by the compiler, but by windows.h, and not all translation units actually need to include that header. _WIN32 is defined by the compiler, and boost has the similar BOOST_MSVC preprocessor define which could also be used. While there is some disagreement among the existing boost libraries about the best mechanism to check this, some check _WIN32, some check BOOST_MSVC, and some check both or others at the same time. I propose the following patch to the 1.45.0 boost::polygon sources to make the detection of the MSVC compiler more robust. Regards, Josh Pieper Index: boost/polygon/gtl.hpp =================================================================== --- boost/polygon/gtl.hpp +++ boost/polygon/gtl.hpp @@ -12,7 +12,7 @@ #pragma warning (disable:1125) #endif -#ifdef WIN32 +#ifdef _WIN32 #pragma warning( disable: 4996 ) #pragma warning( disable: 4800 ) #endif Index: polygon/isotropy.hpp =================================================================== --- boost/polygon/isotropy.hpp +++ boost/polygon/isotropy.hpp @@ -48,7 +48,7 @@ #include <boost/mpl/or.hpp> #else -#ifdef WIN32 +#ifdef _WIN32 #define BOOST_POLYGON_MSVC #endif #ifdef __ICC @@ -290,7 +290,7 @@ template <typename T> struct gtl_if { -#ifdef WIN32 +#ifdef _WIN32 typedef gtl_no type; #endif };
When creating a c++ console solution/project in msvc, by default defines WIN32 - this seems to be the case for both msvc 2008 & 2010. More information: http://stackoverflow.com/questions/662084/whats-the-difference-between-the-w... On 29/11/2010 6:17 AM, Josh Pieper wrote:
I propose the following patch to the 1.45.0 boost::polygon sources to make the detection of the MSVC compiler more robust.
Regards, Josh Pieper
Josh Pieper wrote:
Hello,
I have been compiling boost::polygon under Windows (VS2008, MSVC9.0 specifically) and have run into a minor problem with boost::polygon's detection of Microsoft's compiler. Specifically, it tests for the WIN32 preprocessor define instead of _WIN32. WIN32 isn't actually defined by the compiler, but by windows.h, and not all translation units actually need to include that header. _WIN32 is defined by the compiler, and boost has the similar BOOST_MSVC preprocessor define which could also be used.
While there is some disagreement among the existing boost libraries about the best mechanism to check this, some check _WIN32, some check BOOST_MSVC, and some check both or others at the same time.
I propose the following patch to the 1.45.0 boost::polygon sources to make the detection of the MSVC compiler more robust.
Regards, Josh Pieper
Index: boost/polygon/gtl.hpp =================================================================== --- boost/polygon/gtl.hpp +++ boost/polygon/gtl.hpp @@ -12,7 +12,7 @@ #pragma warning (disable:1125) #endif
-#ifdef WIN32 +#ifdef _WIN32 #pragma warning( disable: 4996 ) #pragma warning( disable: 4800 ) #endif Index: polygon/isotropy.hpp =================================================================== --- boost/polygon/isotropy.hpp +++ boost/polygon/isotropy.hpp @@ -48,7 +48,7 @@ #include <boost/mpl/or.hpp> #else
-#ifdef WIN32 +#ifdef _WIN32 #define BOOST_POLYGON_MSVC #endif #ifdef __ICC @@ -290,7 +290,7 @@
template <typename T> struct gtl_if { -#ifdef WIN32 +#ifdef _WIN32 typedef gtl_no type; #endif };
I can fix this for the next release, however, for the second change it should actually use BOOST_POLYGON_MSVC and not _WIN32. It was an oversight on my part that it was using the WIN32 instead of BOOST_POLYGON_MSVC macro. It was a bug fix I added for older versions of the ICC compiler (and EDG frontend in general) which weren't doing SFINAE properly in a way that was mutually exclusive with the way MSVC 7.1, 8 and 9 doesn't do SFINAE properly. Gcc worked either way so I singled out MSVC for the special behavior so that gcc, icc and all compilers that might use old versions of EDG frontend that I don't know about would work by default. Apparently when I made the fix I used the wrong macro name. I doubt you are using Polygon with BOOST_POLYGON_NO_DEPS defined, so it is the second instance of WIN32 that was causing you trouble and it was my error in using WIN32 instead of BOOST_POLYGON_MSVC that caused you the problem. You should see a commit to trunk soon. Thanks, Luke
On Mon, Nov 29, 2010 at 11:31:03AM -0800, Simonson, Lucanus J wrote:
I can fix this for the next release, however, for the second change it should actually use BOOST_POLYGON_MSVC and not _WIN32. It was an oversight on my part that it was using the WIN32 instead of BOOST_POLYGON_MSVC macro. It was a bug fix I added for older versions of the ICC compiler (and EDG frontend in general) which weren't doing SFINAE properly in a way that was mutually exclusive with the way MSVC 7.1, 8 and 9 doesn't do SFINAE properly. Gcc worked either way so I singled out MSVC for the special behavior so that gcc, icc and all compilers that might use old versions of EDG frontend that I don't know about would work by default. Apparently when I made the fix I used the wrong macro name. I doubt you are using Polygon with BOOST_POLYGON_NO_DEPS defined, so it is the second instance of WIN32 that was causing you trouble and it was my error in using WIN32 instead of BOOST_POLYGON_MSVC that caused you the problem. You should see a commit to trunk soon.
Surely Boost.Config contains Boost-global functionality for platform detection? -- Lars Viklund | zao@acc.umu.se
Lars Viklund wrote:
On Mon, Nov 29, 2010 at 11:31:03AM -0800, Simonson, Lucanus J wrote:
I can fix this for the next release, however, for the second change it should actually use BOOST_POLYGON_MSVC and not _WIN32. It was an oversight on my part that it was using the WIN32 instead of BOOST_POLYGON_MSVC macro. It was a bug fix I added for older versions of the ICC compiler (and EDG frontend in general) which weren't doing SFINAE properly in a way that was mutually exclusive with the way MSVC 7.1, 8 and 9 doesn't do SFINAE properly. Gcc worked either way so I singled out MSVC for the special behavior so that gcc, icc and all compilers that might use old versions of EDG frontend that I don't know about would work by default. Apparently when I made the fix I used the wrong macro name. I doubt you are using Polygon with BOOST_POLYGON_NO_DEPS defined, so it is the second instance of WIN32 that was causing you trouble and it was my error in using WIN32 instead of BOOST_POLYGON_MSVC that caused you the problem. You should see a commit to trunk soon.
Surely Boost.Config contains Boost-global functionality for platform detection?
Indeed it does, and by default BOOST_POLYGON_MSVC is defined if BOOST_MSVC is defined. Only if the user defines BOOST_POLYGON_NO_DEPS does Polygon attempt to compile without any dependency on boost what-so-ever and in that case I set BOOST_POLYGON_MSVC if I detect WIN32 macro is defined. #ifndef BOOST_POLYGON_NO_DEPS #include <boost/config.hpp> #ifdef BOOST_MSVC #define BOOST_POLYGON_MSVC #endif ... #else #ifdef _WIN32 #define BOOST_POLYGON_MSVC #endif ... #endif ... template <typename T> struct gtl_if { #ifdef BOOST_POLYGON_MSVC typedef gtl_no type; #endif }; template <> struct gtl_if<gtl_yes> { typedef gtl_yes type; }; Above we see the fixed version of the code where I use the _WIN32 in no deps mode and BOOST_POLYGON_MSVC later which is defined only if BOOST_MSVC is defined or both _WIN32 and BOOST_POLYGON_NO_DEPS are defined. The no dependencies mode of building Boost.Polygon is part of the legacy of developing it in an environment where usage of boost libraries was prohibited, but is still useful for unit testing. I don't have to configure my build environment at all or even have boost installed. I can just define BOOST_POLYGON_NO_DEPS and I'm off to the races debugging and testing my code. Regards, Luke
participants (4)
-
Arash Partow -
Josh Pieper -
Lars Viklund -
Simonson, Lucanus J