From: Shane L. <lie...@gm...> - 2014-01-31 08:38:51
|
Has anybody had any success building a portable version of SWIG for the Mac? I've already got swigwin embedded directly in my source tree, and would like to investigate the possibility of doing something similar for the Mac -- it would help ensure consistency between the platforms for this project by ensuring the SWIG versions were always synced up. Basically thinking something along the same lines as freezing Ruby gems into a distributed project... I know how to get SWIG building and installing to a given prefix, but the Mac is a little more finicky about absolute filepaths and system headers. If anyone else has attempted this, has a makefile at the ready, etc., any guidance would be appreciated. (Also, if this is a terribly catastrophic idea for reasons I am not considering, reasonable scolding with brief explanations would also be appreciated. :) ) |
From: Andy S. <and...@gm...> - 2014-01-31 14:02:06
|
I've always just installed swig using homebrew, they have a pretty simple ruby file which just calls make. Might want to take a look at it and see if that helps. We do have a number of third party libs embedded in our project tree, I just have cmake call the make file of these to build them. Should be pretty easy to just call the swig make file? On Friday, January 31, 2014, Shane Liesegang <lie...@gm...> wrote: > Has anybody had any success building a portable version of SWIG for the > Mac? > > I've already got swigwin embedded directly in my source tree, and would > like to investigate the possibility of doing something similar for the Mac > -- it would help ensure consistency between the platforms for this project > by ensuring the SWIG versions were always synced up. Basically thinking > something along the same lines as freezing Ruby gems into a distributed > project... > > I know how to get SWIG building and installing to a given prefix, but the > Mac is a little more finicky about absolute filepaths and system headers. > If anyone else has attempted this, has a makefile at the ready, etc., any > guidance would be appreciated. > > (Also, if this is a terribly catastrophic idea for reasons I am not > considering, reasonable scolding with brief explanations would also be > appreciated. :) ) > |
From: Bradley L. <blo...@ma...> - 2014-01-31 14:08:51
|
Hello, I do this we a CMake ExternalProject in a Superbuild: https://github.com/SimpleITK/SimpleITK/blob/master/SuperBuild/External_Swig.cmake Brad On Jan 31, 2014, at 3:38 AM, Shane Liesegang <lie...@gm...> wrote: > Has anybody had any success building a portable version of SWIG for the Mac? > > I've already got swigwin embedded directly in my source tree, and would like to investigate the possibility of doing something similar for the Mac -- it would help ensure consistency between the platforms for this project by ensuring the SWIG versions were always synced up. Basically thinking something along the same lines as freezing Ruby gems into a distributed project... > > I know how to get SWIG building and installing to a given prefix, but the Mac is a little more finicky about absolute filepaths and system headers. If anyone else has attempted this, has a makefile at the ready, etc., any guidance would be appreciated. > > (Also, if this is a terribly catastrophic idea for reasons I am not considering, reasonable scolding with brief explanations would also be appreciated. :) ) > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk_______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user |
From: William S F. <ws...@fu...> - 2014-01-31 18:58:31
|
On 31/01/14 14:08, Bradley Lowekamp wrote: > Hello, > > I do this we a CMake ExternalProject in a Superbuild: > > https://github.com/SimpleITK/SimpleITK/blob/master/SuperBuild/External_Swig.cmake Brad, or anyone else... I'd quite like a CMakeLists.txt file distributed with SWIG for building the SWIG binaries for those who don't want to/can't use autoconf. I thought your CMake file would build it but on closer inspection it seems not. There is a more standard CMakeLists.txt from which it could be based on at https://github.com/oliver----/swig-v8/blob/devel/CMakeLists.txt. I would want a common file between autoconf and cmake containing the list of files to build though. BTW, have you submitted or thought about submitting std_vector_for_R_swig.i as a patch for future inclusion? William |
From: Bradley L. <blo...@ma...> - 2014-01-31 19:22:36
|
William, You are right, the script I have is to building SWIG with it's autoconf system from within a CMake project, as an "external project". Having SWIG full build,install,package and test with CMake would be great. I think it would be really great over all and very helpful to getting SWIG to more easily compile on windows. And the ctest/cdash infrastructure can be used for a nightly dashboard of regression tests, as well as a way for other (me) to contribute to testing. Richard Beare did the initial work with getting R to work with my project. He contributed some of the changes upstream. I haven't check to see how that is not working upstream, but there appears to be some of his contribution up there. The other patches I have[1], I pull from upstream to get it working across on the platforms and languages I'm testing on. [1] https://github.com/SimpleITK/SimpleITK/tree/master/SuperBuild/Swig-patch On Jan 31, 2014, at 1:58 PM, William S Fulton <ws...@fu...> wrote: > On 31/01/14 14:08, Bradley Lowekamp wrote: >> Hello, >> >> I do this we a CMake ExternalProject in a Superbuild: >> >> https://github.com/SimpleITK/SimpleITK/blob/master/SuperBuild/External_Swig.cmake > Brad, or anyone else... I'd quite like a CMakeLists.txt file distributed with SWIG for building the SWIG binaries for those who don't want to/can't use autoconf. > > I thought your CMake file would build it but on closer inspection it seems not. There is a more standard CMakeLists.txt from which it could be based on at https://github.com/oliver----/swig-v8/blob/devel/CMakeLists.txt. I would want a common file between autoconf and cmake containing the list of files to build though. > > BTW, have you submitted or thought about submitting std_vector_for_R_swig.i as a patch for future inclusion? > > William > |
From: William S F. <ws...@fu...> - 2014-01-31 23:48:53
|
Hi Bradley About 10 years ago Bill Hoffman put in a really great effort to port the SWIG build and testing to CMake with some initial results being posted on the ctest dashboard. This looked quite good, but fizzled out in the end, I think because it would have taken too much effort to port all the numerous target language tests to CMake. This seemed to be the goal at the time, that is, completely replace the autotools. We are using Travis for our testing nowadays, but this is currently limited to Ubuntu and more recently Mac as well. It does cover all the well supported languages (11 of them) using the autotools test-suite. We can always do with more testing especially on other operating systems. I'd love to have a way to test Solaris and Windows in particular, even if it was just a handful of languages. Testing these is tedious to do before a release and spotty at best. If it is easy to put together CMake tests for even just one or two languages on these missing operating systems, I'd be very happy. However, I'd really need someone to get it up and running as I already spend a disproportionately large amount of time on testing! If it used common inputs to the autotools then it will be easy to maintain going forwards (just a few things like test file names and SWIG source file names). William On 31/01/14 19:22, Bradley Lowekamp wrote: > William, > > You are right, the script I have is to building SWIG with it's > autoconf system from within a CMake project, as an "external > project". > > Having SWIG full build,install,package and test with CMake would be > great. I think it would be really great over all and very helpful to > getting SWIG to more easily compile on windows. And the ctest/cdash > infrastructure can be used for a nightly dashboard of regression > tests, as well as a way for other (me) to contribute to testing. > > Richard Beare did the initial work with getting R to work with my > project. He contributed some of the changes upstream. I haven't > check to see how that is not working upstream, but there appears to > be some of his contribution up there. The other patches I have[1], I > pull from upstream to get it working across on the platforms and > languages I'm testing on. > > [1] > https://github.com/SimpleITK/SimpleITK/tree/master/SuperBuild/Swig-patch > > > > On Jan 31, 2014, at 1:58 PM, William S Fulton > <ws...@fu...> wrote: > >> On 31/01/14 14:08, Bradley Lowekamp wrote: >>> Hello, >>> >>> I do this we a CMake ExternalProject in a Superbuild: >>> >>> https://github.com/SimpleITK/SimpleITK/blob/master/SuperBuild/External_Swig.cmake >> >>> >>> Brad, or anyone else... I'd quite like a CMakeLists.txt file >>> distributed with SWIG for building the SWIG binaries for those >>> who don't want to/can't use autoconf. >> >> I thought your CMake file would build it but on closer inspection >> it seems not. There is a more standard CMakeLists.txt from which >> it could be based on at >> https://github.com/oliver----/swig-v8/blob/devel/CMakeLists.txt. I >> would want a common file between autoconf and cmake containing the >> list of files to build though. >> >> BTW, have you submitted or thought about submitting >> std_vector_for_R_swig.i as a patch for future inclusion? >> >> William >> > > |
From: Bradley L. <blo...@ma...> - 2014-02-05 14:17:12
|
William, Just to follow up with this. It sounds like a lot of work to maintain two build/test systems. I don't for see myself getting any idle time in the near future to dabble in this. Regarding the number of languages supported. Currently for our SimpleITK project we are building and testing wrapping for Python, CSharp, Java, Lua, Tcl, Ruby, and R. The CMake code that we have written so far for this is not generic, nor very pretty. It is in need of a refactoring though, so maybe I can keep generality in mind during the refactor. The most challenging thing has been get language packaging working for a couple languages, fortunately that is not a SWIG issue. I understand becoming a slave to testing and maintaining a clean portable system. Here is the CDash board for SimpleITK ( looking a little red ): http://open.cdash.org/index.php?project=SimpleITK&date=2014-02-04 Thanks again for the great tools. Brad On Jan 31, 2014, at 6:48 PM, William S Fulton <ws...@fu...> wrote: > Hi Bradley > > About 10 years ago Bill Hoffman put in a really great effort to port the SWIG build and testing to CMake with some initial results being posted on the ctest dashboard. This looked quite good, but fizzled out in the end, I think because it would have taken too much effort to port all the numerous target language tests to CMake. This seemed to be the goal at the time, that is, completely replace the autotools. > > We are using Travis for our testing nowadays, but this is currently limited to Ubuntu and more recently Mac as well. It does cover all the well supported languages (11 of them) using the autotools test-suite. We can always do with more testing especially on other operating systems. I'd love to have a way to test Solaris and Windows in particular, even if it was just a handful of languages. Testing these is tedious to do before a release and spotty at best. If it is easy to put together CMake tests for even just one or two languages on these missing operating systems, I'd be very happy. However, I'd really need someone to get it up and running as I already spend a disproportionately large amount of time on testing! If it used common inputs to the autotools then it will be easy to maintain going forwards (just a few things like test file names and SWIG source file names). > > William > > > On 31/01/14 19:22, Bradley Lowekamp wrote: >> William, >> >> You are right, the script I have is to building SWIG with it's >> autoconf system from within a CMake project, as an "external >> project". >> >> Having SWIG full build,install,package and test with CMake would be >> great. I think it would be really great over all and very helpful to >> getting SWIG to more easily compile on windows. And the ctest/cdash >> infrastructure can be used for a nightly dashboard of regression >> tests, as well as a way for other (me) to contribute to testing. >> >> Richard Beare did the initial work with getting R to work with my >> project. He contributed some of the changes upstream. I haven't >> check to see how that is not working upstream, but there appears to >> be some of his contribution up there. The other patches I have[1], I >> pull from upstream to get it working across on the platforms and >> languages I'm testing on. >> >> [1] >> https://github.com/SimpleITK/SimpleITK/tree/master/SuperBuild/Swig-patch >> >> >> > > On Jan 31, 2014, at 1:58 PM, William S Fulton >> <ws...@fu...> wrote: >> >>> On 31/01/14 14:08, Bradley Lowekamp wrote: >>>> Hello, >>>> >>>> I do this we a CMake ExternalProject in a Superbuild: >>>> >>>> https://github.com/SimpleITK/SimpleITK/blob/master/SuperBuild/External_Swig.cmake >>> >>>> >>>> Brad, or anyone else... I'd quite like a CMakeLists.txt file >>>> distributed with SWIG for building the SWIG binaries for those >>>> who don't want to/can't use autoconf. >>> >>> I thought your CMake file would build it but on closer inspection >>> it seems not. There is a more standard CMakeLists.txt from which >>> it could be based on at >>> https://github.com/oliver----/swig-v8/blob/devel/CMakeLists.txt. I >>> would want a common file between autoconf and cmake containing the >>> list of files to build though. >>> >>> BTW, have you submitted or thought about submitting >>> std_vector_for_R_swig.i as a patch for future inclusion? >>> >>> William >>> >> >> > |