From: Oliver B. <oli...@go...> - 2012-04-21 11:49:25
|
Hi William and list, I want to bring another topic into discussion. Though, I think there is really no hurry. CMake is becoming more and more the next-generation cross platform build configuration tool. I personally have worked with it now over 2 years and find it very intuitive. In my github branch repos I have added support for CMake. Find the commit here: https://github.com/oliver----/swig-v8/commit/76ff613d613f83ae9a31cb1d2956d45b4981270d Though, it is only a first shot - not a thorough solution yet. Just for you to see how it smells and how minimal invasive such support could be. I want to know if you are basically interested - or nay, never. Regards, Oliver |
From: Vadim Z. <vz...@ze...> - 2012-04-21 12:47:43
|
On Sat, 21 Apr 2012 13:42:32 +0200 Oliver Buchtala <oli...@go...> wrote: OB> CMake is becoming more and more the next-generation cross platform build OB> configuration tool. I really don't think it's an undisputed champion of cross platform build tools. There are many other ones and IMO cmake is far from being the best. I don't want to start discussion about this here (although I can give my reasons if you're interested) but the point is that there is absolutely no consensus about cmake being, or becoming, the obvious best choice. FWIW my personal opinion is that it would be quite difficult to reproduce SWIG build system, in particular its test suite, in any other tool. Building SWIG itself is trivial and, in fact, I sometimes do it with a single command line using MSVC under Windows, but the rest of makefiles is complicated and the best would be IMHO to just leave them be. Regards, VZ |
From: Oliver B. <oli...@go...> - 2012-04-21 13:54:22
|
Am 21.04.2012 14:47, schrieb Vadim Zeitlin: > On Sat, 21 Apr 2012 13:42:32 +0200 Oliver Buchtala<oli...@go...> wrote: > > OB> CMake is becoming more and more the next-generation cross platform build > OB> configuration tool. > > I really don't think it's an undisputed champion of cross platform build > tools. There are many other ones and IMO cmake is far from being the best. > I don't want to start discussion about this here (although I can give my > reasons if you're interested) but the point is that there is absolutely no > consensus about cmake being, or becoming, the obvious best choice. You are right: this is definitely a discussed topic without consensus. For example there is gyp and qmake. Personally I have not seen 'the best'. For me CMake was definitely the one easiest to understand from the beginning. I just see more and more large projects using CMake. There are definitely some fans ;) But of course also are others. And you are right, there is no essential need to change the configuration system. For the CMake users it would be sugar - and that describes very much the priority of such a work. > FWIW my personal opinion is that it would be quite difficult to reproduce > SWIG build system, in particular its test suite, in any other tool. > Building SWIG itself is trivial and, in fact, I sometimes do it with a > single command line using MSVC under Windows, but the rest of makefiles is > complicated and the best would be IMHO to just leave them be. I am actually not very into the complicated stuff of swig's makefiles. The testing could probably be realized with CMake's CTest. Can you give me a hint about one of these problematic parts in the swig configuration? Just for me to see and understand the problem horizon... Oliver |
From: Miles B. <mi...@gn...> - 2012-04-21 23:01:10
|
Oliver Buchtala <oli...@go...> writes: > Personally I have not seen 'the best'. For me CMake was definitely the > one easiest to understand from the beginning. The way I think of it is, they all suck, just in different ways... :] -miles -- Friendship, n. A ship big enough to carry two in fair weather, but only one in foul. |
From: Oliver B. <oli...@go...> - 2012-04-21 14:11:00
|
Am 21.04.2012 14:47, schrieb Vadim Zeitlin: > FWIW my personal opinion is that it would be quite difficult to reproduce > SWIG build system, in particular its test suite, in any other tool. > Building SWIG itself is trivial and, in fact, I sometimes do it with a > single command line using MSVC under Windows, but the rest of makefiles is > complicated and the best would be IMHO to just leave them be. > > Regards, > VZ > small addition: I would actually not dare to replace the existing build chain. I just thought that for some users this extra tool support could be nice. ... yes... redundancy is bad ;) Regards, Oliver |
From: Oliver B. <oli...@go...> - 2012-04-27 08:01:46
|
Just for the interest of CMake friends ;) I haven't been aware of the great integration of CMake into kdevelop4. It's really worth a look if you don't know already... Oliver |
From: William S F. <ws...@fu...> - 2012-04-21 23:01:55
|
On 21/04/12 12:42, Oliver Buchtala wrote: > Hi William and list, > > I want to bring another topic into discussion. Though, I think there is > really no hurry. > > CMake is becoming more and more the next-generation cross platform build > configuration tool. > I personally have worked with it now over 2 years and find it very > intuitive. > > In my github branch repos I have added support for CMake. > Find the commit here: > https://github.com/oliver----/swig-v8/commit/76ff613d613f83ae9a31cb1d2956d45b4981270d > > Though, it is only a first shot - not a thorough solution yet. > Just for you to see how it smells and how minimal invasive such support > could be. > > I want to know if you are basically interested - or nay, never. > > Regards, > Oliver > > SWIG worked with Kitware back in 2003 to develop CMakeLists.txt files for SWIG and they put in a lot of effort to meet SWIG's requirements. Here is the main discussion thread: http://thread.gmane.org/gmane.comp.programming.swig.devel/12380 It kind of fizzled out in the end, mainly because of the huge effort that would be required to fully move over to CMake as SWIG supports so many different languages. One can put together a CMakeLists.txt relatively easily for building SWIG, but without a build system for the examples and most importantly, the test-suite, no serious development can be done. The work done in 2003 had a replacement CMake build for the SWIG executable and test-suite for something like Java, Python and another language or two. I really like the concept of CMake, especially new generators like Eclipse makefiles. I have used it professionally for some SWIG projects, but found that a lot of CMake scripts needed to be written for the non-C++ testing and in the end there is not too much that can be leveraged from CMake for non-C++ testing. A lot of platform specific code had to be written and getting this right isn't easy as debugging the makefiles it generates ain't simple. Makefile debugging isn't simple at the best of times, but generated ones are that bit worse. I wouldn't be averse to having a CMakeLists.txt alongside the automake files for building the two SWIG executables. Normally, I would be against having a duplicate build system, but currently there is no real native Windows build and rather than providing the missing visual studio solution file, a CMake build would offer more and adding new files into two build systems is non-trivial and probably can be sourced from one single file anyway. I also wouldn't object to anyone brave enough to replace the complete build system with CMake equivalent, but would expect that to be quite non-trivial. William |
From: Oliver B. <oli...@go...> - 2012-04-21 23:12:03
|
Am 22.04.2012 01:01, schrieb William S Fulton: > On 21/04/12 12:42, Oliver Buchtala wrote: >> Hi William and list, >> >> I want to bring another topic into discussion. Though, I think there is >> really no hurry. >> >> CMake is becoming more and more the next-generation cross platform build >> configuration tool. >> I personally have worked with it now over 2 years and find it very >> intuitive. >> >> In my github branch repos I have added support for CMake. >> Find the commit here: >> https://github.com/oliver----/swig-v8/commit/76ff613d613f83ae9a31cb1d2956d45b4981270d >> >> >> Though, it is only a first shot - not a thorough solution yet. >> Just for you to see how it smells and how minimal invasive such support >> could be. >> >> I want to know if you are basically interested - or nay, never. >> >> Regards, >> Oliver >> >> > > SWIG worked with Kitware back in 2003 to develop CMakeLists.txt files > for SWIG and they put in a lot of effort to meet SWIG's requirements. > Here is the main discussion thread: > http://thread.gmane.org/gmane.comp.programming.swig.devel/12380 > > It kind of fizzled out in the end, mainly because of the huge effort > that would be required to fully move over to CMake as SWIG supports so > many different languages. One can put together a CMakeLists.txt > relatively easily for building SWIG, but without a build system for > the examples and most importantly, the test-suite, no serious > development can be done. The work done in 2003 had a replacement CMake > build for the SWIG executable and test-suite for something like Java, > Python and another language or two. > > I really like the concept of CMake, especially new generators like > Eclipse makefiles. I have used it professionally for some SWIG > projects, but found that a lot of CMake scripts needed to be written > for the non-C++ testing and in the end there is not too much that can > be leveraged from CMake for non-C++ testing. A lot of platform > specific code had to be written and getting this right isn't easy as > debugging the makefiles it generates ain't simple. Makefile debugging > isn't simple at the best of times, but generated ones are that bit worse. Ooookay - I understand :) That's true, other languages than C/C++ and CMake do (still) not work well together... Me quiet ;) Oliver |
From: Bill H. <bil...@ki...> - 2012-04-23 13:46:27
|
On 4/21/2012 7:01 PM, William S Fulton wrote: > On 21/04/12 12:42, Oliver Buchtala wrote: >> Hi William and list, >> >> I want to bring another topic into discussion. Though, I think there is >> really no hurry. >> >> CMake is becoming more and more the next-generation cross platform build >> configuration tool. >> I personally have worked with it now over 2 years and find it very >> intuitive. >>... > > SWIG worked with Kitware back in 2003 to develop CMakeLists.txt files > for SWIG and they put in a lot of effort to meet SWIG's requirements. > Here is the main discussion thread: > http://thread.gmane.org/gmane.comp.programming.swig.devel/12380 > > It kind of fizzled out in the end, mainly because of the huge effort > that would be required to fully move over to CMake as SWIG supports so > many different languages. One can put together a CMakeLists.txt > relatively easily for building SWIG, but without a build system for the > examples and most importantly, the test-suite, no serious development > can be done. The work done in 2003 had a replacement CMake build for the > SWIG executable and test-suite for something like Java, Python and > another language or two. > ... > I wouldn't be averse to having a CMakeLists.txt alongside the automake > files for building the two SWIG executables. Normally, I would be > against having a duplicate build system, but currently there is no real > native Windows build and rather than providing the missing visual studio > solution file, a CMake build would offer more and adding new files into > two build systems is non-trivial and probably can be sourced from one > single file anyway. > > I also wouldn't object to anyone brave enough to replace the complete > build system with CMake equivalent, but would expect that to be quite > non-trivial. > > William > We did put a lot of effort into support for CMake and Swig back then. I think the testing system should have no problem handling swig. I think the main reason it died was that no one in the Swig community really adopted it. I don't think it is because CMake can not work with the tests or languages needed by Swig. The ctest system in CMake actually still has some of the features in it that we created specifically for swig to allow for the large number of tests. If someone wants to pick this up, I should be able to help in an advisory role. Thanks. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bil...@ki... http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 |
From: Oliver B. <oli...@go...> - 2012-04-23 16:58:01
|
Am 23.04.2012 15:46, schrieb Bill Hoffman: > On 4/21/2012 7:01 PM, William S Fulton wrote: >> On 21/04/12 12:42, Oliver Buchtala wrote: >>> Hi William and list, >>> >>> I want to bring another topic into discussion. Though, I think there is >>> really no hurry. >>> >>> CMake is becoming more and more the next-generation cross platform >>> build >>> configuration tool. >>> I personally have worked with it now over 2 years and find it very >>> intuitive. >>> ... >> >> SWIG worked with Kitware back in 2003 to develop CMakeLists.txt files >> for SWIG and they put in a lot of effort to meet SWIG's requirements. >> Here is the main discussion thread: >> http://thread.gmane.org/gmane.comp.programming.swig.devel/12380 >> >> It kind of fizzled out in the end, mainly because of the huge effort >> that would be required to fully move over to CMake as SWIG supports so >> many different languages. One can put together a CMakeLists.txt >> relatively easily for building SWIG, but without a build system for the >> examples and most importantly, the test-suite, no serious development >> can be done. The work done in 2003 had a replacement CMake build for the >> SWIG executable and test-suite for something like Java, Python and >> another language or two. >> > ... >> I wouldn't be averse to having a CMakeLists.txt alongside the automake >> files for building the two SWIG executables. Normally, I would be >> against having a duplicate build system, but currently there is no real >> native Windows build and rather than providing the missing visual studio >> solution file, a CMake build would offer more and adding new files into >> two build systems is non-trivial and probably can be sourced from one >> single file anyway. >> >> I also wouldn't object to anyone brave enough to replace the complete >> build system with CMake equivalent, but would expect that to be quite >> non-trivial. >> >> William >> > We did put a lot of effort into support for CMake and Swig back then. > I think the testing system should have no problem handling swig. I > think the main reason it died was that no one in the Swig community > really adopted it. I don't think it is because CMake can not work > with the tests or languages needed by Swig. The ctest system in > CMake actually still has some of the features in it that we created > specifically for swig to allow for the large number of tests. > > If someone wants to pick this up, I should be able to help in an > advisory role. > > Thanks. > > -Bill > > Hmmm. Personally I am not sure, yet. Yesterday I have looked a bit around in the test-suite. Indeed there is much stuff where CMake does not provide special support, i.e., things that would be executed using COMMANDs. Not that it wouldn't be possible, though it would not look simpler than the makefiles either. And definitely, transferring the whole thing would be quite an effort. And as you say, not without an explicit interest of the swig community. From my technical experience with CMake I could definitely cope with that task. Nevertheless, the next months are for GSoC. Time to let more people think about that... Oliver |