From: Marvin G. <pub...@gm...> - 2014-02-21 21:08:14
|
I've submitted a pull request with some patches that allow building swig and the test suites using the Microsoft compilers. For more details see https://github.com/swig/swig/pull/141. I've only run the csharp test suite so far. I'd be shocked if this works for all the language test suites, but I leveraged (and worked around) existing autotools capabilities, so it should be a step in the right direction. Getting MS compilers to do anything is a pain, so this will probably be an evolution to support all the language modules. More eyes on this is probably warranted since I'm an autotools newbie. Marvin |
From: William S F. <ws...@fu...> - 2014-02-24 20:12:22
|
On 21/02/14 21:08, Marvin Greenberg wrote: > I've submitted a pull request with some patches that allow building swig > and the test suites using the Microsoft compilers. For more details see > https://github.com/swig/swig/pull/141. > > I've only run the csharp test suite so far. I'd be shocked if this > works for all the language test suites, but I leveraged (and worked > around) existing autotools capabilities, so it should be a step in the > right direction. Getting MS compilers to do anything is a pain, so this > will probably be an evolution to support all the language modules. More > eyes on this is probably warranted since I'm an autotools newbie. > Just a follow up as Marvin closed the patch and maybe others here might be interested. I use cccl on Windows which is a front end to make cl.exe look like gcc. It makes the windows compiler fit in with the way autotools work and works reasonably well and allows me to run the test-suite for a handful of languages (but with some example Makefile modifications). https://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-projects-under-msvc-part-one/ mentions the original cccl on SF which I use (slightly modified), but also refers to some updates by balabit in a git repo. If there is interest, I'd not oppose putting this into a github repo for maintenance under the SWIG organisation, if patches are needed and not accepted by balabit. The windows development needs improving and I feel CMake is the only viable long term solution for this though. Mainly because it is designed to support target languages and understands Windows properly and provide a proper Visual Studio solution. Two useful reference email chains are http://sourceforge.net/mailarchive/message.php?msg_id=29161022 and http://sourceforge.net/mailarchive/message.php?msg_id=31910482 William |
From: William S F. <ws...@fu...> - 2014-02-24 20:15:11
|
On 24/02/14 20:11, William S Fulton wrote: > On 21/02/14 21:08, Marvin Greenberg wrote: >> I've submitted a pull request with some patches that allow building swig >> and the test suites using the Microsoft compilers. For more details see >> https://github.com/swig/swig/pull/141. >> >> I've only run the csharp test suite so far. I'd be shocked if this >> works for all the language test suites, but I leveraged (and worked >> around) existing autotools capabilities, so it should be a step in the >> right direction. Getting MS compilers to do anything is a pain, so this >> will probably be an evolution to support all the language modules. More >> eyes on this is probably warranted since I'm an autotools newbie. >> > Just a follow up as Marvin closed the patch and maybe others here might > be interested. > > I use cccl on Windows which is a front end to make cl.exe look like gcc. > It makes the windows compiler fit in with the way autotools work and > works reasonably well and allows me to run the test-suite for a handful > of languages (but with some example Makefile modifications). > https://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-projects-under-msvc-part-one/ > mentions the original cccl on SF which I use (slightly modified), but > also refers to some updates by balabit in a git repo. If there is > interest, I'd not oppose putting this into a github repo for maintenance > under the SWIG organisation, if patches are needed and not accepted by > balabit. > > The windows development needs improving and I feel CMake is the only > viable long term solution for this though. Mainly because it is designed > to support target languages and understands Windows properly and provide > a proper Visual Studio solution. Two useful reference email chains are > http://sourceforge.net/mailarchive/message.php?msg_id=29161022 and > http://sourceforge.net/mailarchive/message.php?msg_id=31910482 Incidentally, I fixed the C# example solution files for 64 bit a couple of days ago and have tested with VS2005 and VS2010. Anyone who has a later versions of Visual Studio, please double check that they work. William |
From: William S F. <ws...@fu...> - 2014-02-25 20:30:16
|
On 24/02/14 20:14, William S Fulton wrote: > On 24/02/14 20:11, William S Fulton wrote: >> On 21/02/14 21:08, Marvin Greenberg wrote: >>> I've submitted a pull request with some patches that allow building swig >>> and the test suites using the Microsoft compilers. For more details see >>> https://github.com/swig/swig/pull/141. >>> >>> I've only run the csharp test suite so far. I'd be shocked if this >>> works for all the language test suites, but I leveraged (and worked >>> around) existing autotools capabilities, so it should be a step in the >>> right direction. Getting MS compilers to do anything is a pain, so this >>> will probably be an evolution to support all the language modules. More >>> eyes on this is probably warranted since I'm an autotools newbie. >>> >> Just a follow up as Marvin closed the patch and maybe others here might >> be interested. >> >> I use cccl on Windows which is a front end to make cl.exe look like gcc. >> It makes the windows compiler fit in with the way autotools work and >> works reasonably well and allows me to run the test-suite for a handful >> of languages (but with some example Makefile modifications). >> https://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-projects-under-msvc-part-one/ >> >> mentions the original cccl on SF which I use (slightly modified), but >> also refers to some updates by balabit in a git repo. If there is >> interest, I'd not oppose putting this into a github repo for maintenance >> under the SWIG organisation, if patches are needed and not accepted by >> balabit. >> >> The windows development needs improving and I feel CMake is the only >> viable long term solution for this though. Mainly because it is designed >> to support target languages and understands Windows properly and provide >> a proper Visual Studio solution. Two useful reference email chains are >> http://sourceforge.net/mailarchive/message.php?msg_id=29161022 and >> http://sourceforge.net/mailarchive/message.php?msg_id=31910482 > > Incidentally, I fixed the C# example solution files for 64 bit a couple > of days ago and have tested with VS2005 and VS2010. Anyone who has a > later versions of Visual Studio, please double check that they work. Travis may one day have Windows support, but anyone interested in improving Windows testing now could set up appveyor - http://www.appveyor.com/. It provides a near equivalent to Travis for Windows and is free for open source projects. It has Visual Studio pre-installed and Chocolatey could be used to install cygwin/mingw/cccl/whatever else to kick off a build/test. And probably just C# and Java would be easy to get working using autoconf. William |
From: Marvin G. <pub...@gm...> - 2014-02-27 17:39:12
|
William S Fulton wrote: > On 24/02/14 20:11, William S Fulton wrote: > > Incidentally, I fixed the C# example solution files for 64 bit a couple > of days ago and have tested with VS2005 and VS2010. Anyone who has a > later versions of Visual Studio, please double check that they work. I finally found a machine I could use, with W7-64 and VS2013. VS2012 and VS2013 have changed the project file format (vcprojx instead of vcproj) but it converts them automatically. Tons of indecipherable warnings. They seemed ignorable. I pointed and clicked all the solution files under Examples/csharp. The only definite problem I found was in the solution file in Examples/csharp/nested It did not have x64 configuration available in pulldown, Only Win32 and "Mixed Platforms". I'm guessing this is therefor VS2010 too. There are some warnings during the build because of the custom output location for the DLL, and this: LNK4075: ignoring '/EDITANDCONTINUE' due to '/SAFESEH' specification 1 Probably don't matter. I also checked the properties used to build the various dlls. They correctly have /EHsc, usefully adds /RTC1 (extra runtime checks). OTOH, it seems that the dll gets built with /MTd instead of /MDd. /MDd says it is used to link with the multithreaded DLL library (instead of the plain multithreaded library used for executables.) The calling convention used is __cdecl (/Gd) not __stdcall (/Gz) This seems to be the default and I don't really grok the difference especially when you read this sentence from msdn.microsoft.com/en-us/library/fwkeyyhe.aspx: /Gd Uses the __cdecl callin convention (x86 only) /Gz Uses the __stdcall... (x86 only) So calling convention does not matter on x64? We also use /Zi and /GR, which can help when debugging. Honestly, I don't know too much about the right flags and settings for correctly compiling on visual studio. Marvin |
From: William S F. <ws...@fu...> - 2014-03-01 12:40:52
|
On 27/02/14 17:39, Marvin Greenberg wrote: > William S Fulton wrote: >> On 24/02/14 20:11, William S Fulton wrote: > >> >> Incidentally, I fixed the C# example solution files for 64 bit a couple >> of days ago and have tested with VS2005 and VS2010. Anyone who has a >> later versions of Visual Studio, please double check that they work. > > I finally found a machine I could use, with W7-64 and VS2013. VS2012 > and VS2013 have changed the project file format (vcprojx instead of > vcproj) but it converts them automatically. Tons of indecipherable > warnings. They seemed ignorable. > > I pointed and clicked all the solution files under Examples/csharp. > > The only definite problem I found was in the solution file in > Examples/csharp/nested > It did not have x64 configuration available in pulldown, Only Win32 and > "Mixed Platforms". I'm guessing this is therefor VS2010 too. > > There are some warnings during the build because of the custom output > location for the DLL, and this: > > LNK4075: ignoring '/EDITANDCONTINUE' due to '/SAFESEH' specification 1 > > Probably don't matter. > Ah, I missed the nested example. I've updated it now. > I also checked the properties used to build the various dlls. They > correctly have /EHsc, usefully adds /RTC1 (extra runtime checks). OTOH, > it seems that the dll gets built with /MTd instead of /MDd. /MDd says > it is used to link with the multithreaded DLL library (instead of the > plain multithreaded library used for executables.) > The example code is all included in the one example.dll, so it doesn't matter too much if the C++ runtime is a dll or statically linked. However, /MDd would be better if the examples were linking to other dlls. > The calling convention used is __cdecl (/Gd) not __stdcall (/Gz) > This seems to be the default and I don't really grok the difference > especially when you read this sentence from > msdn.microsoft.com/en-us/library/fwkeyyhe.aspx: > /Gd Uses the __cdecl callin convention (x86 only) > /Gz Uses the __stdcall... (x86 only) > So calling convention does not matter on x64? > > We also use /Zi and /GR, which can help when debugging. > > Honestly, I don't know too much about the right flags and settings for > correctly compiling on visual studio. > Do they examples run successfully? If they do, then that seems good enough for me. These flags could be tweaked endlessly. William |