From: Alan W. I. <ir...@be...> - 2006-07-04 17:47:01
|
The article, "Why the KDE project switched to CMake -- and how" by Alexander Neundorf (now freely accessible at http://lwn.net/Articles/188693/) is a must-read for everyone who develops for a project which either (a) uses autotools for a build system or (b) supports building on the "bare windows" platform (i.e., a window's platform without Cygwin or MinGW/MSYS). PLplot qualifies on both counts. The following two paragraphs from the article strongly resonated with me: "In KDE3 development, we ended up with an autotools-based build system that most of our developers did not fully understand. I estimate that no more than 10 people were able to fix any major problem occurring with it, first and foremost our "buildsystem-guru" Stephan Kulow. Over the years, these guys must have been contacted by hundreds of co-developers with requests for help to fix build problems in specific applications and modules." "So, among KDE developers, and probably the developers of other autotools-based projects, there is the opinion that dealing with the build system is hard, almost higher magic. This is a myth. A myth created by autotools. CMake is able to destroy this myth. Yes, there is a new syntax for the CMakeLists.txt files, but it is easy to learn." PLplot has a similar problem only worse because there is only one "buildsystem-guru" in PLplot (Rafael) that really understands autotools. I am probably the second most experienced with it, but I still view a lot of it as higher magic. So one potential benefit of CMake for us would be that every PLplot developer should be able to quickly understand and update our build system. That should free us from the current situation where we depend completely on Rafael (or some guru from the libtool list) to figure out the hard problems. There are apparently a number of other potential benefits of using CMake; it is truly cross-platform so that it not only works on all the systems where autotools currently works but also on bare windows. This would allow a truly integrated build system so that bare-windows configuration work would directly benefit the Unix side of things and vice versa. Furthermore, from the Scribus experience described in a side bar to the article, the CMake approach apparently produces 5 times smaller Makefiles which are produced 5 times more quickly than the equivalent autotools result. With all these apparent CMake positives, I don't yet have any practical CMake experience so I am concerned there are negatives that the article did not mention and only practical experience will tell whether any of those exist for PLplot or not. Nevertheless, if such complicated projects as KDE and Scribus are able to switch from autotools to CMake (the latter in a week starting from no CMake experience at all!), then I expect most/all of the negatives we would have encountered with versions of CMake prior to 2.4.2 have been dealt with in version 2.4.2 (the version which includes all the KDE feedback and which was used by Scribus for their quick conversion). Rafael has objected off list to me that if the autotools approach is not broken for us then why should we fix it? There is some validity to that conservative approach, but on the other hand all the benefits mentioned above are fairly compelling. For example, I am sure the Unix/Linux developers here have all noticed how long cf/bootstrap.sh and ./configure are taking to complete these days. Reduction of that latency by a factor of 5 would be most welcome. Anyhow, my conclusion is the CMake build method is certainly worth trying. Fortunately, that can be done without interfering with the autotools-based approach since the CMake infrastructure (which apparently consists only of CMakeLists.txt files) does not interfere with any of the autotools related files. So the nice thing is we should be able to develop the CMake approach right on CVS HEAD and let everyone evaluate the "cmake .; make; make install" by comparing its results directly with results from the autotools-based "cf/bootstrap.sh; ./configure; make; make install". So conceivably we could have both build systems coexisting peacefully for several years until there is no longer any interest in maintaining one of them. The time scale for trying out CMake really depends on how many other PLplot developers are interested. I would be willing to help with the creation of the required CMakeLists.txt files as well as test results on the Linux side of things, but my time is limited so I hope others are interested as well. In particular, I hope the "bare windows" developers here (e.g., Arjen and Jim) are interested since they would potentially have an especially large benefit from such an approach. Anyhow, I ask all PLplot developers here to please read the above article and let me know (preferably on list) what you think. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2006-07-04 18:06:14
|
Alan, What is it like for language support? I know that it has been something of a headache in the past supporting some of our bindings with autotools. I'm thinking particularly of Java, and the recent F95 problems. I should say I have no experience at all of cmake, so I'm cautious about voicing any opinions. I suspect most of the developers are the same. Andrew On Tue, Jul 04, 2006 at 10:46:07AM -0700, Alan Irwin wrote: > The article, "Why the KDE project switched to CMake -- and how" by Alexander > Neundorf (now freely accessible at http://lwn.net/Articles/188693/) is a > must-read for everyone who develops for a project which either (a) uses > autotools for a build system or (b) supports building on the "bare windows" > platform (i.e., a window's platform without Cygwin or MinGW/MSYS). PLplot > qualifies on both counts. > > The following two paragraphs from the article strongly resonated with me: > > "In KDE3 development, we ended up with an autotools-based build system that > most of our developers did not fully understand. I estimate that no more > than 10 people were able to fix any major problem occurring with it, first > and foremost our "buildsystem-guru" Stephan Kulow. Over the years, these > guys must have been contacted by hundreds of co-developers with requests for > help to fix build problems in specific applications and modules." > > "So, among KDE developers, and probably the developers of other > autotools-based projects, there is the opinion that dealing with the build > system is hard, almost higher magic. This is a myth. A myth created by > autotools. CMake is able to destroy this myth. Yes, there is a new syntax > for the CMakeLists.txt files, but it is easy to learn." > > PLplot has a similar problem only worse because there is only one > "buildsystem-guru" in PLplot (Rafael) that really understands autotools. I > am probably the second most experienced with it, but I still view a lot of > it as higher magic. > > So one potential benefit of CMake for us would be that every PLplot > developer should be able to quickly understand and update our build system. > That should free us from the current situation where we depend completely on > Rafael (or some guru from the libtool list) to figure out the hard problems. > > There are apparently a number of other potential benefits of using CMake; it > is truly cross-platform so that it not only works on all the systems where > autotools currently works but also on bare windows. This would allow a > truly integrated build system so that bare-windows configuration work would > directly benefit the Unix side of things and vice versa. Furthermore, from > the Scribus experience described in a side bar to the article, the CMake > approach apparently produces 5 times smaller Makefiles which are produced 5 > times more quickly than the equivalent autotools result. > > With all these apparent CMake positives, I don't yet have any practical > CMake experience so I am concerned there are negatives that the article did > not mention and only practical experience will tell whether any of those > exist for PLplot or not. Nevertheless, if such complicated projects as KDE > and Scribus are able to switch from autotools to CMake (the latter in a week > starting from no CMake experience at all!), then I expect most/all of the > negatives we would have encountered with versions of CMake prior to 2.4.2 > have been dealt with in version 2.4.2 (the version which includes all the > KDE feedback and which was used by Scribus for their quick conversion). > > Rafael has objected off list to me that if the autotools approach is not > broken for us then why should we fix it? There is some validity to that > conservative approach, but on the other hand all the benefits mentioned > above are fairly compelling. For example, I am sure the Unix/Linux > developers here have all noticed how long cf/bootstrap.sh and ./configure > are taking to complete these days. Reduction of that latency by a factor of > 5 would be most welcome. > > Anyhow, my conclusion is the CMake build method is certainly worth trying. > Fortunately, that can be done without interfering with the autotools-based > approach since the CMake infrastructure (which apparently consists only of > CMakeLists.txt files) does not interfere with any of the autotools related > files. So the nice thing is we should be able to develop the CMake approach > right on CVS HEAD and let everyone evaluate the "cmake .; make; make > install" by comparing its results directly with results from the > autotools-based "cf/bootstrap.sh; ./configure; make; make install". So > conceivably we could have both build systems coexisting peacefully for > several years until there is no longer any interest in maintaining one of > them. > > The time scale for trying out CMake really depends on how many other PLplot > developers are interested. I would be willing to help with the creation of > the required CMakeLists.txt files as well as test results on the Linux side > of things, but my time is limited so I hope others are interested as well. > In particular, I hope the "bare windows" developers here (e.g., Arjen and > Jim) are interested since they would potentially have an especially large > benefit from such an approach. > > Anyhow, I ask all PLplot developers here to please read the above article > and let me know (preferably on list) what you think. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the > Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Arjen M. <arj...@wl...> - 2006-07-05 06:25:51
|
Andrew Ross wrote: >Alan, > >What is it like for language support? I know that it has been something of >a headache in the past supporting some of our bindings with autotools. >I'm thinking particularly of Java, and the recent F95 problems. > >I should say I have no experience at all of cmake, so I'm cautious >about voicing any opinions. I suspect most of the developers are the >same. > > Same goes for me - I browsed through the article a bit and through the comments that were posted. It seems to create _native_ makefiles based on the configuration information you give it. Well, in essence that is what the autotools are doing too. But I am indeeed concerned about the language support, not to mention all the libraries and fonts and ... autotools now find out for you. I do not oppose this, but it requires serious consideration of the benefits and the disadvantages. Regards, Arjen |
From: <hba...@ma...> - 2006-07-15 00:28:36
|
On Jul 11, 2006, at 2:37 AM, Alan W. Irwin wrote: > > Let me know whether using a clean source tree and separate build > tree gives > you a lot better result. If not, I am confident I can fix it since > Mac OS X > has been one of the supported CMake platforms for a long time now. I tried again with a fresh checkout of PLplot, and now I get: iMac ~/Documents/OpenSource/PLplot/plplot-cmake : cmake . -- Check for working C compiler: gcc -- Check for working C compiler: gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: c++ -- Check for working CXX compiler: c++ -- works -- Looking for popen -- Looking for popen - found -- Looking for usleep -- Looking for usleep - found -- Looking for isinf -- Looking for isinf - found -- Looking for finite -- Looking for finite - found -- Looking for isnan -- Looking for isnan - found CMake Error: Error in cmake code at /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cmake/cmake/ modules/plplot.cmake:48: INCLUDE called with wrong number of arguments. Include only takes one file. -- Check for using namespace support -- Check for using namespace - found -- Looking for C++ include cmath -- Looking for C++ include cmath - found -- Check for broken isnan support in <cmath> -- Check for isnan in <cmath> - found -- Check for using stdint.h with CXX compiler -- Check for using stdint.h with CXX compiler - ok -- Check for working Fortran compiler: gfortran -- Check for working Fortran compiler: gfortran -- works -- Checking whether gfortran supports Fortran 90 -- Checking whether gfortran supports Fortran 90 -- yes -- Looking for pkg-config -- Looking for pkg-config - found DEVICES_LIST = DRIVERS_LIST = libplplotd_LINK_FLAGS = libplplotd_COMPILE_FLAGS = Full paths: /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cmake/ bindings/java/config.java;/Users/hbabcock/Documents/OpenSource/PLplot/ plplot-cmake/bindings/java/plplotjavacJNI.java;/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/bindings/java/ PLGraphicsIn.java;/Users/hbabcock/Documents/OpenSource/PLplot/plplot- cmake/bindings/java/plplotjavacConstants.java;/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/bindings/java/plplotjavac.java CMake Error: Error in cmake code at /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cmake/bindings/ java/CMakeLists.txt:72: Unknown CMake command "SWIG_ADD_MODULE". CMake Error: Error in cmake code at /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cmake/bindings/ java/CMakeLists.txt:73: Unknown CMake command "SWIG_LINK_LIBRARIES". CPACK_SOURCE_IGNORE_FILES = Makefile\\.in$;~$;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake.*/CVS/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/bindings/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/cf/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/debian/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/doc/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/drivers/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/examples/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/fonts/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/libltdl/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/old/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/pkgcfg/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/rpm/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/scripts/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/sys/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/test/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cmake/utils/ -- Configuring done Ideas? -Hazen |
From: Andrew R. <and...@us...> - 2006-07-15 11:11:42
|
Hazen, I think this is probably because you don't have swig installed / cmake couldn't find it. I've now added a check in so you should be ok. Swig related files are only included if swig is detected. As it stands you won't be able to build the java bindings. Cheers Andrew On Fri, Jul 14, 2006 at 08:27:39PM -0400, hba...@ma... wrote: > > I tried again with a fresh checkout of PLplot, and now I get: > > iMac ~/Documents/OpenSource/PLplot/plplot-cmake : cmake . > -- Check for working C compiler: gcc > -- Check for working C compiler: gcc -- works > -- Check size of void* > -- Check size of void* - done > -- Check for working CXX compiler: c++ > -- Check for working CXX compiler: c++ -- works > -- Looking for popen > -- Looking for popen - found > -- Looking for usleep > -- Looking for usleep - found > -- Looking for isinf > -- Looking for isinf - found > -- Looking for finite > -- Looking for finite - found > -- Looking for isnan > -- Looking for isnan - found > CMake Error: Error in cmake code at > /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cmake/cmake/ > modules/plplot.cmake:48: > INCLUDE called with wrong number of arguments. Include only takes > one file. > -- Check for using namespace support > -- Check for using namespace - found > -- Looking for C++ include cmath > -- Looking for C++ include cmath - found > -- Check for broken isnan support in <cmath> > -- Check for isnan in <cmath> - found > -- Check for using stdint.h with CXX compiler > -- Check for using stdint.h with CXX compiler - ok > -- Check for working Fortran compiler: gfortran > -- Check for working Fortran compiler: gfortran -- works > -- Checking whether gfortran supports Fortran 90 > -- Checking whether gfortran supports Fortran 90 -- yes > -- Looking for pkg-config > -- Looking for pkg-config - found > DEVICES_LIST = > DRIVERS_LIST = > libplplotd_LINK_FLAGS = > libplplotd_COMPILE_FLAGS = > Full paths: /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cmake/ > bindings/java/config.java;/Users/hbabcock/Documents/OpenSource/PLplot/ > plplot-cmake/bindings/java/plplotjavacJNI.java;/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/bindings/java/ > PLGraphicsIn.java;/Users/hbabcock/Documents/OpenSource/PLplot/plplot- > cmake/bindings/java/plplotjavacConstants.java;/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/bindings/java/plplotjavac.java > CMake Error: Error in cmake code at > /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cmake/bindings/ > java/CMakeLists.txt:72: > Unknown CMake command "SWIG_ADD_MODULE". > CMake Error: Error in cmake code at > /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cmake/bindings/ > java/CMakeLists.txt:73: > Unknown CMake command "SWIG_LINK_LIBRARIES". > CPACK_SOURCE_IGNORE_FILES = Makefile\\.in$;~$;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake.*/CVS/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/bindings/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/cf/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/debian/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/doc/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/drivers/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/examples/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/fonts/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/libltdl/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/old/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/pkgcfg/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/rpm/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/scripts/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/sys/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/test/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cmake/utils/ > -- Configuring done > > Ideas? > > -Hazen > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Werner S. <sm...@ia...> - 2006-07-05 11:57:59
|
Hi, here ( http://en.wikipedia.org/wiki/CMake ) I found the following: # Automatic dependency analysis built-in for C, C++, Fortran and Java, # Support of SWIG, Qt, FLTK via the CMake scripting langage, # Built-in support for Microsoft Visual Studio .NET and past Visual Studio versions, including generation of .dsp, .dsw, .sln and .vcproj files, so fortran and java are also supported. Regards, Werner Arjen Markus wrote: > Hello, > > the site for CMake, http://www.cmake.org/, does not mention > anything at all about programming languages (or else I have missed > the information). All documentation seems geared to C++. > > I have no doubt it will be possible to add support for other language > by defining the proper rules and so on, but that looks like a lot of > work to me. > > Regards, > > Arjen > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2006-07-04 19:26:06
|
On 2006-07-04 19:06+0100 Andrew Ross wrote: > > Alan, > > What is it like for language support? I know that it has been something of > a headache in the past supporting some of our bindings with autotools. > I'm thinking particularly of Java, and the recent F95 problems. Yes, we required the help of a libtool guru to get fortran 95 working (albeit with the F77=whatever workaround) and also to get the PLplot build system to work with a beta of libtool-2.0. Furthermore, my work in putting in the autotools infrastructure to support our fortran 95 interface was not negligible. Thus, from these recent less-than-positive experiences, I am certainly open to autotools alternatives and that is the reason why I paid such close attention to this article. I should caution the article said nothing about language support although there definitely must be some since KDE supports a number of different language bindings. > > I should say I have no experience at all of cmake, so I'm cautious > about voicing any opinions. I suspect most of the developers are the > same. I am in the exact same position since so far my only source of information is the article. However, I see no downsides to giving CMake a try since it can peacefully coexist with autotools and (from the article) the syntax is really easy to learn. So the real question here is whether some other developers want to help me out with giving CMake a try. What I probably should do is start with just the core libplplot build, and see whether others become interested once I get that small subset of our build working using CMake. Alan > > Andrew > > On Tue, Jul 04, 2006 at 10:46:07AM -0700, Alan Irwin wrote: >> The article, "Why the KDE project switched to CMake -- and how" by Alexander >> Neundorf (now freely accessible at http://lwn.net/Articles/188693/) is a >> must-read for everyone who develops for a project which either (a) uses >> autotools for a build system or (b) supports building on the "bare windows" >> platform (i.e., a window's platform without Cygwin or MinGW/MSYS). PLplot >> qualifies on both counts. __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2006-07-05 03:27:30
|
On 2006-07-04 12:26-0700 Alan W. Irwin wrote: > On 2006-07-04 19:06+0100 Andrew Ross wrote: >> I should say I have no experience at all of cmake, so I'm cautious >> about voicing any opinions. I suspect most of the developers are the >> same. > > I am in the exact same position since so far my only source of information > is the article. However, I see no downsides to giving CMake a try since it > can peacefully coexist with autotools and (from the article) the syntax is > really easy to learn. So the real question here is whether some other > developers want to help me out with giving CMake a try. > > What I probably should do is start with just the core libplplot build, and > see whether others become interested once I get that small subset of our > build working using CMake. I did something even simpler. (1) I built and installed CMake-2.4.2 from source following the instructions at http://www.cmake.org/HTML/Install.html. 2.4.2 is the recommended version since early versions don't have all the KDE feedback. This build step is necessary on Debian stable, Ubuntu dapper, and probably most other Linux distros, although Debian testing and Debian unstable have already packaged CMake-2.4.2. (2) I then followed one of the simple examples to create CMakeLists.txt files that would build our csirocsa and csironn libraries which libplplot depends upon. The result of these files (mostly consisting of one line) and the commands "cmake ." and "make" was a successful static library build of libcsirocsa.a and libcsironn.a. I ask that others try this out on their own platforms (especially Mac OS X and bare windows). Even for these two simple lib/csa and lib/nn directories there is obviously more to do such as install documentation and provide the shared library build capability, but for now we have a modest start that seems promising. I have cvs committed these CMakeLists.txt files, and as time permits I intend to upgrade these CMakeLists.txt files to deal with the issues I mentioned above and also to start creating CMakeLists.txt files in other directories as well. I strongly encourage others to do the same. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2006-07-05 09:39:28
|
Hello, the site for CMake, http://www.cmake.org/, does not mention anything at all about programming languages (or else I have missed the information). All documentation seems geared to C++. I have no doubt it will be possible to add support for other language by defining the proper rules and so on, but that looks like a lot of work to me. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2006-07-05 12:17:44
|
Werner Smekal wrote: >Hi, > >here ( http://en.wikipedia.org/wiki/CMake ) > >I found the following: > ># Automatic dependency analysis built-in for C, C++, Fortran and Java, ># Support of SWIG, Qt, FLTK via the CMake scripting langage, ># Built-in support for Microsoft Visual Studio .NET and past Visual >Studio versions, including generation of .dsp, .dsw, .sln and .vcproj files, > >so fortran and java are also supported. > > > That is encouraging, but from my (admittedly short) survey this did not become clear at all. And it leaves the question of mixed-language issues wide open ... (I seem to feel a trifle grumpy - must the holiday that is nearing ;)) Regards, Arjen |
From: Andrew R. <and...@us...> - 2006-07-05 15:36:59
|
On Wed, Jul 05, 2006 at 02:17:34PM +0200, Arjen Markus wrote: > > > That is encouraging, but from my (admittedly short) survey this did not > become > clear at all. And it leaves the question of mixed-language issues wide > open ... > (I seem to feel a trifle grumpy - must the holiday that is nearing ;)) I took a look at the source. I can see some support for java - including code to find the compiler and the jni headers. I can see some support for fortran. It just looks for a "fortran compiler". It also searches the commercials fortran compilers first, before trying the GNU compilers. Once it finds a compiler it will test to see if it supports F90. There is no documentation on this other than the code itself as far as I can see. The other thing that occurs to me is that cmake does the configuring as part of the cmake process, so as I understand it there is no configure script to distribute. This means any user wanting to build plplot must have cmake installed. To me this seems a disadvantage when compared to the current autotools setup. For KDE I guess this doesn't matter. Who build that from source? For plplot it is more of an issue. Something to think about. Andrew |
From: Alan W. I. <ir...@be...> - 2006-07-05 17:39:18
|
On 2006-07-05 08:25+0200 Arjen Markus wrote: > Andrew Ross wrote: > >> Alan, >> >> What is it like for language support? I know that it has been something of >> a headache in the past supporting some of our bindings with autotools. >> I'm thinking particularly of Java, and the recent F95 problems. >> >> I should say I have no experience at all of cmake, so I'm cautious >> about voicing any opinions. I suspect most of the developers are the >> same. >> >> > Same goes for me - I browsed through the article a bit and through the > comments that were posted. It seems to create _native_ makefiles based > on the configuration information you give it. Correct. For example, on Linux systems it generates short Makefiles based on the powerful features of GNU make. > Well, in essence that is what > the autotools are doing too. Not exactly. Automake uses a lowest-common-denominator approach so the generated Makefiles will work on all Unix systems. The result on Linux is none of the powerful features of GNU make are used, and the generated Makefiles are extremely large and take a long time to generate. In fact from the Scribus sidebar to the article the autotools-generated Makefiles were 5 times longer and took 5 times longer to generate than the equivalent CMake result. I have also seen a claim in the KDE CMake Wiki that the actual make command done afterward is a lot faster for KDE because execution of the horribly long and complicated libtool script is avoided. That claim seems reasonable to me since I have seen quite a slowdown in the PLplot examples build if the libtool-based plplot-config approach is used rather than (the now default) pkg-config approach. > I do not oppose this, but it requires serious consideration of the > benefits and the > disadvantages. My attitude is that "serious consideration" you mention has already been done by both the KDE and Scribus projects. By direct comparisons with their existing autotools approaches, they have proved that CMake is right for them in terms of the build efficiency (see above), ease of configuration, and cross-platform support on both bare windows systems and all Linux/Unix systems. Those good results for those complicated projects make me confident that CMake will also give good results for PLplot. Thus, because the excellent chance of immediate success, I think the best approach for evaluating CMake for our needs is simply to see how far we can get with building PLplot using CMake. CMake and autotools build systems peacefully coexist so the worst that could happen with this "try-it-and-see" approach is we hit some strange PLplot/CMake build system issue that delays our full use of CMake until it can be dealt with by the CMake developers. Every developer who is considering helping should be aware of that possible downside, but my personal decision is to participate in the CMake effort for PLplot because (a) I feel that PLplot/CMake failure is an unlikely scenario given the KDE and Scribus success, and (b) I believe because of that success CMake will spread to many projects and gain a lot of mind share in the FLOSS community so the CMake expertise I build up during the PLplot effort will be useful to me for many years to come. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <fu...@li...> - 2006-07-05 18:49:43
|
I have a few thoughts on the CMake business, that I would like to share. I won't try to do it as a quoted response type email in this case, just because there has already been so much traffic on the subject, and it's hard to go back and find all the parts I might want to respond to (I get huge quantities of work related email, beyond just the PLplot stuff). The first thing I should say, is that I want to be extremely careful in this e-mail, and in any followup, to tread lightly with respect to all the work that was done on the autotools cutover, and the support therof since. As most will remember, neither Maurice nor I found that proposition to be at all compelling (to us), but we agreed to it on the basic condition that whoever did the cutover, would be responsible for supporting it, and for dealing with all the myriad "PLplot won't build right on my system" complaints that we knew would inevitably come in. (As they have). From my perspective, Rafael (mostly) and Alan (also) have done a fantastic job of meeting the support requirement, for this cutover from the old system to the current, both for the countless general user help requests, and even for my own build system support requests, where I was forced to ask for help because I couldn't see how to do some things on my own. So, I want to acknowledge all of that, with deep gratitude, and be clear that in my ensuing comments, I mean no disrespect to that effort. Not to belabor the point, but I would just point out, that from my limited perspective, it seems to me that a huge fraction of all the energy going into PLplot these days, is going into specifically areas that relate directly to improving the user experience (as opposed to plotting/graphics feature development). Bindings development is the part of that which results in actual coding development. But beyond that, there is a lot of work which traces directly to multi-platform support, fine tuning, etc. This is the area which always required the most work--a veritably suffocating level of such work--in the old system, and which Maurice and I both cautioned would have to be borne in the autotools cutover. I think, to be very succinct here, that it was the view of the autotools proponents that using autotools would be a critical tool in addressing that need. Since I haven't been personally doing that support in this era, I don't have a particularly clear personal perspective on how successful this has been. I see that a ton of work has gone into this type of thing. Others would have to judge whether or not autotools has really delivered the anticipated tool-backed infrastructure strength, flexibility and agility that was needed. What I can say, is that from my personal perspective, the autotools system is bulky, slow, and essentially impenetrable. Not just the process of constructing the configure script, or of running it for the system analysis. That is slow, much slower than I think could possibly really be necessary, but that is the least of my issues with it. What drives me nuts about it, is that the build process for plplot itself, is so completely obfuscated by the system. It might be hard to remember, since the cutover was so long ago, and many of the current PLplot core team members are new since then anyway, but the old build process used to result in lines of visible output to the screen, along the lines of: gcc <flags> -c plXYZ..c gcc <flags> -c plUVW..c and a duplicate set along the lines of: gcc <flags> -fPIC -c plXYZ..c -o shares/plXYZ.o gcc <flags> -fPIC -c plUVW..c -o shared/plUVW.o There were a couple of varitions on exactly how the PIC versus non-PIC variants were handled, but the above is a servicable schematic. The current (autotools) build system presumably has such lines buried in there somewhere, but they essentially can't be found (my perspective), and the system appears to me to compile much more slowly since the autotools cutover. I've never done a direct side by side compile time comparison between the new and old PLplot build systems, but I'm pretty sure the new (crrent) one is a /lot/ slower, and I know (that from my personal perspective) it is a lot harder to read and comprehend. Neither Maurice nor I have complained much about this in public e-mail, for the simple reason that we turned it (the build system) over, on the condition that the proponents of the new system do the support, and that has happened. So, if you guys like it better, and you're supporting it (as you are), then why would we complain? But do I (and I think Maurice is in basic agreement, to make this "I" a "we") think it is "good" in absolute terms? No. >From my perspective, a "good" build system should have a few basic properties. 1) Simple 2) Fast 3) Flexible "Power" isn't a specific requirement, but it might be a key way to get any of 1, 2 or 3. In order to be "fast", there shouldn't be much, if anything, happening during the compilation of a translation unit, other than just running the compiler. Any determination of options, settings, system characteristics that impinge on either, etc, should all be hoisted to a pre-compile phase where such static decisions are made and recorded. By the time you get to a makefile, you shouldn't need to do anything but run the compiler. As far as what make system to use, it is very hard for me to see any actual need for a new system compilation tool. I haven't read the CMake article yet. I'll try to do so soon. But, I spent too much time in my early years learning tricks to deal with all the inconceivably braindead "vendor make's" that are out there, and I have one simple stock ansser: use GNU make. GNU make is on every platform that matters, as far as I know. And presents the same, powerful features to all. There is /nothing/ that I build, in my outside-PLPlot career as a software developer, that I do not build with GNU make. [Aside: Okay, okay, so for some Java software ant has been found to be better than make, but that's only because it hooks into the Java compiler's dependency analysis system--far as I can see, it's nothing that couldn't be achieved with GNU make if the Java compiler jocks would open up their dependency and class recompilation engine for a little more optimal traversal thereof.] Anyway, my point is, for C/C++ code, I just use GNU make, and honestly cannot understand the clamor for anything else. And there's been a lot of clamor in the world at large. CMake is just the latest in a long string of make-replacements that have been advocated through the years. Every one I've inspected in any detail, had just seemed dumb to me. None has brought anything that couldn't be achieved with GNU make. That doesn't mean I'm opposed to CMake, just that I can't (yet?) fathom the need. But if a CMake-based system satisfies 1), 2) and 3), then I could be okay with it. Especially if it is 1) and 2), then I would expect in the end, to like it a lot better than PLplot's current build system. But the user experience has to be accounted for. And I (and I'm sure Maurice), will still want others on the core team to be responsible for supporting it, at least initially. If we adopt a new system that achieves simplicity, then maybe that won't be such an issue. But we kind of need to see that play out in practice, not just posit that it will be so, sight unseen. The mere fact of needing to obtain CMake to build PLplot would not deter me from adopting it. If someone's going to build PLplot, they'll have to do a certain amount of tool assemblage, and fetching the requisite build system would be just one such item on a checklist. The world is already getting gummed up with software that needs bjam (hey, there's yet another anti-GNU-make system that probably should also get a serious look-see if we're actually thinking about swtiching). And ant. And jam. etc. So, having to fetch CMake wouldn't actually be such a foreign experience, in and of itself. But what does happen--and the people who support PLplot inevitably see this over time--is that users write in with all kinds of bizarre build failure reports, and they have to be debugged, and the system improved to cover that wierdness in the user's environment, which none of us could've imagined in advance. That has played out countless times in the past, and will happen countless more times in the future. It is the number one burden in supporting PLplot, in my opinion. So, things that help that mission, in the eyes of the people most directly doing that support, are good. I would say that independent of what happens with CMake from a developer convenience perspective, the user support equation can only be judged over time. Developer convenience is of course important. Like I said, I'd like the build to result in successive cleartext invocations of gcc (or other selected compiler) on each PLplot source file, and nothing more. But no matter how good CMake may prove to be at facilitating the developer experience, the heavy weight in the balance is always going to be the flexibiltiy with respect to servicing user requests stemming from failed builds in the field. |
From: Alan W. I. <ir...@be...> - 2006-07-05 20:17:12
|
On 2006-07-05 13:49-0500 Geoffrey Furnish wrote: > Anyway, my point is, for C/C++ code, I just use GNU make, and honestly cannot > understand the clamor for anything else. And there's been a lot of clamor in > the world at large. CMake is just the latest in a long string of > make-replacements that have been advocated through the years. Every one I've > inspected in any detail, had just seemed dumb to me. None has brought > anything that couldn't be achieved with GNU make. To clear up that misconception, CMake simply prepares Makefiles which on Linux systems use all the powerful facilities of GNU make. So invocation is like this: cmake OPTIONS PATH make make install That's it. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <fu...@li...> - 2006-07-05 20:59:23
|
Alan W. Irwin writes: > On 2006-07-05 13:49-0500 Geoffrey Furnish wrote: > > > Anyway, my point is, for C/C++ code, I just use GNU make, and honestly > > cannot understand the clamor for anything else. And there's been a lot > > of clamor in the world at large. CMake is just the latest in a long > > string of make-replacements that have been advocated through the years. > > Every one I've inspected in any detail, had just seemed dumb to me. > > None has brought anything that couldn't be achieved with GNU make. > > To clear up that misconception, CMake simply prepares Makefiles which on > Linux systems use all the powerful facilities of GNU make. So invocation is > like this: > > cmake OPTIONS PATH > make > make install Right, I understand. What I was trying to say was, I don't see a compelling reason to have something which makes a makefile. One can just directly write a GNU makefile, and I have never found this to be insufficient. To the extent that there is some static system analysis that should be factored into the build, a "configure" script can just write that one file, and the GNU-make-based build system can just include that file to pick up the configuration. There are extremely powerful transformation rules and "extended macro" definition facilities all in GNU make. I have never found anything build related that I needed, that I couldn't do just fine, in just GNU make. The result is typically a very compact, very simple, and very fast build environment. Note: the old PLplot build system is not really an example of what I am saying one can do in GNU make. So if anyone's out there scratching their head saying, "The old PLplot build system didn't sound like that to me", well, that's not what I'm saying. All I am saying is, if one were to dump autotools, and go back to a simpler approach, I don't see why it should really be necessary to adopt CMake, or any of the other build-system-construction tools. IMO, just plain ol' GNU make, is basically all anyone could seriously need. Which does not mean that I am either for or against CMake. I was just trying to express my views of the general issues with multi-platform project build systems. In the FWIW category. |
From: <mj...@br...> - 2006-07-06 08:17:47
|
Geoffrey Furnish writes: > Note: the old PLplot build system is not really an example of what I am > saying one can do in GNU make. So if anyone's out there scratching their > head saying, "The old PLplot build system didn't sound like that to me", > well, that's not what I'm saying. All I am saying is, if one were to dump > autotools, and go back to a simpler approach, I don't see why it should > really be necessary to adopt CMake, or any of the other > build-system-construction tools. IMO, just plain ol' GNU make, is basically > all anyone could seriously need. In fact the old PLplot build system specifically avoided reliance on GNU make b/c at the time it wasn't near as universally available as today. In 1993, a port of what we'd consider today a "standard Unix tool" to a foreign Unix variant could be a real (unwelcome) adventure. So the old build system used autoconf to construct makefile "fragments", which were pieced together by file concatenation to make the makefile, nicely doing away with the need for a make include facility. Speaking of autoconf, what about all the autoconf-[un]defined macros in the source files, to handle POSIX facilities etc? Does CMake handle all these transparently? -- Maurice LeBrun |
From: Alan W. I. <ir...@be...> - 2006-07-05 21:01:35
|
On 2006-07-05 16:36+0100 Andrew Ross wrote: > On Wed, Jul 05, 2006 at 02:17:34PM +0200, Arjen Markus wrote: >>> >> That is encouraging, but from my (admittedly short) survey this did not >> become >> clear at all. And it leaves the question of mixed-language issues wide >> open ... >> (I seem to feel a trifle grumpy - must the holiday that is nearing ;)) > > I took a look at the source. I can see some support for java - including > code to find the compiler and the jni headers. I can see some support > for fortran. It just looks for a "fortran compiler". It also searches > the commercials fortran compilers first, before trying the GNU > compilers. Once it finds a compiler it will test to see if it supports > F90. There is no documentation on this other than the code itself as far > as I can see. I agree that documentation is a problem for CMake in the sense that it is scattered in a fairly large number of places. However, because of the recent positive publicity I think there will be a lot of autotools-based projects converting to CMake. That sharply increased mindshare probably means we can get the answers we need from google searches and eventually those answers should also be available in the various CMake wikis and eventually in the more formal documentation. > > The other thing that occurs to me is that cmake does the configuring as > part of the cmake process, so as I understand it there is no configure > script to distribute. This means any user wanting to build plplot must > have cmake installed. That is correct. However, I think cmake is in the process of becoming an ubiquitous system tool. For example, Debian testing and unstable have already packaged the required version (2.4.2) of cmake, and I think other distros will soon follow suit. Those who don't yet have access to the 2.4.2 version of cmake in packaged form will have to build it themselves, but I proved last night that was a much simpler process than a typical PLplot build so I am not going to worry too much about this issue. Thanks, Arjen, Geoffrey, and Andrew for responding to my request to discuss CMake on list, and I hope my answers to your concerns have reassured you. In any case, I see no downside to at least trying to create a CMake-based build system for PLplot so I am going ahead with that effort and other developers are certainly welcome to participate. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2006-07-06 06:15:33
|
Hi, since I had a look at some of this "make substitutes" (cmake, scons, jam, ...) some time ago, I want just make some short comments: - to have a cross platform solution (and support of many different compilers) in GNU make is really not easy (freetype has a good solution here), especially since using e.g. Visual C++ compiler with GNU make is not perfect, or not that what developers want - this is one of the big advantages of cmake and scons, since they provide native solutions for all supported compilers (dsp files for Visual C++, ...) - this is also a big disadvantage of cmake and scons, since they don't support all compilers at the same level, or there is no documentation (or only little) about the support and so on - and if you start writing cmake or scons scripts for projects which are cross platform (not only unix) and for several compilers they also get *very* complicated and bloated Anyway, cmake is (as scons) a good solution, but be prepared, that it will get complicated as soon as you start to support windows and unix at the same time and several compilers (which would be very useful, to also support e.g. free Borland tools, Open Watcom, digital mars, lc, etc. on Windows). Also I don't know if cmake has configure like possibilities (find out automagically what is installed, etc.) - in scons that is only limited. On the other side plplot is not that big project, that it is not possible to make such a script possible. Since I always wanted to learn cmake, I'll try to help here, especially on the Windows side. And I don't think it's a bad idea to work on cmake file in parallel, it may work, and especially for Windows it might provide a good solution. Regards, Werner Alan W. Irwi"n wrote: > On 2006-07-05 16:36+0100 Andrew Ross wrote: > >> On Wed, Jul 05, 2006 at 02:17:34PM +0200, Arjen Markus wrote: >>> That is encouraging, but from my (admittedly short) survey this did not >>> become >>> clear at all. And it leaves the question of mixed-language issues wide >>> open ... >>> (I seem to feel a trifle grumpy - must the holiday that is nearing ;)) >> I took a look at the source. I can see some support for java - including >> code to find the compiler and the jni headers. I can see some support >> for fortran. It just looks for a "fortran compiler". It also searches >> the commercials fortran compilers first, before trying the GNU >> compilers. Once it finds a compiler it will test to see if it supports >> F90. There is no documentation on this other than the code itself as far >> as I can see. > > I agree that documentation is a problem for CMake in the sense that it is > scattered in a fairly large number of places. However, because of the > recent positive publicity I think there will be a lot of autotools-based > projects converting to CMake. That sharply increased mindshare probably > means we can get the answers we need from google searches and eventually > those answers should also be available in the various CMake wikis and > eventually in the more formal documentation. > >> The other thing that occurs to me is that cmake does the configuring as >> part of the cmake process, so as I understand it there is no configure >> script to distribute. This means any user wanting to build plplot must >> have cmake installed. > > That is correct. However, I think cmake is in the process of becoming an > ubiquitous system tool. For example, Debian testing and unstable have > already packaged the required version (2.4.2) of cmake, and I think other > distros will soon follow suit. Those who don't yet have access to the 2.4.2 > version of cmake in packaged form will have to build it themselves, but I > proved last night that was a much simpler process than a typical PLplot build > so I am not going to worry too much about this issue. > > Thanks, Arjen, Geoffrey, and Andrew for responding to my request to discuss > CMake on list, and I hope my answers to your concerns have reassured you. > In any case, I see no downside to at least trying to create a CMake-based > build system for PLplot so I am going ahead with that effort and other > developers are certainly welcome to participate. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the > Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Arjen M. <arj...@wl...> - 2006-07-06 07:06:22
|
Alan W. Irwin wrote: >That is correct. However, I think cmake is in the process of becoming an >ubiquitous system tool. For example, Debian testing and unstable have >already packaged the required version (2.4.2) of cmake, and I think other >distros will soon follow suit. Those who don't yet have access to the 2.4.2 >version of cmake in packaged form will have to build it themselves, but I >proved last night that was a much simpler process than a typical PLplot build >so I am not going to worry too much about this issue. > >Thanks, Arjen, Geoffrey, and Andrew for responding to my request to discuss >CMake on list, and I hope my answers to your concerns have reassured you. >In any case, I see no downside to at least trying to create a CMake-based >build system for PLplot so I am going ahead with that effort and other >developers are certainly welcome to participate. > > I have read the article now and the messages up to now and feel more inclined to give CMake a try. I do not agree with Alan that KDE's adoption of CMake is a good serious consideration that PLplot can take at face value. The author did have to cooperate with the CMake people, the port to Windows was a severe pain and while I do not know KDE's internals, my guess is that it uses C++ exclusively. Okay, PLplot is much smaller (fortunately) than KDE, but they do very different things in terms of static and dynamic libraries - just think of the language bindings and the different device drivers. Good heavens, there are many many doubts one can raise a priori here. But the best way to get all the pros and cons on the table is that Alan and Werner go ahead and try to implement a build system. Oh, one thing I do want to add: besides the build system, we may also need to worry about the runtime environment - certainly on Windows (which makes it my worry ;)). The dot-net environment will probably become more and more important and I know how to work with it, but I am still in limbo about the true meaning of managed and unmanaged libraries and applications. Regards, Arjen |
From: <hba...@ma...> - 2006-07-11 03:44:06
|
> ubiquitous system tool. For example, Debian testing and unstable have > already packaged the required version (2.4.2) of cmake, and I think > other > distros will soon follow suit. Those who don't yet have access to > the 2.4.2 > version of cmake in packaged form will have to build it themselves, > but I > proved last night that was a much simpler process than a typical > PLplot build > so I am not going to worry too much about this issue. Sorry for the last e-mail, as you clearly stated I need cmake version 2.4.2, which I now have, and with which I get: iMac ~/Documents/OpenSource/PLplot/plplot-cvs : /usr/bin/cmake . -- Check size of void* -- Check size of void* - done DEVICES_LIST = DRIVERS_LIST = CPACK_SOURCE_IGNORE_FILES = Makefile\\.in$;~$;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cvs.*/CVS/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cvs/bindings/;^/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-cvs/cf/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/debian/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/doc/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/drivers/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/examples/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/fonts/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/libltdl/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/old/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/pkgcfg/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/rpm/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/scripts/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/sys/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/test/;^/Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs/utils/ -- Configuring done -- Generating done -- Build files have been written to: /Users/hbabcock/Documents/ OpenSource/PLplot/plplot-cvs iMac ~/Documents/OpenSource/PLplot/plplot-cvs : make Scanning dependencies of target csirocsa Building C object lib/csa/CMakeFiles/csirocsa.dir/csa.o Linking C shared library libcsirocsa.dylib Scanning dependencies of target csironn Building C object lib/nn/CMakeFiles/csironn.dir/delaunay.o Building C object lib/nn/CMakeFiles/csironn.dir/hash.o Building C object lib/nn/CMakeFiles/csironn.dir/istack.o Building C object lib/nn/CMakeFiles/csironn.dir/lpi.o Building C object lib/nn/CMakeFiles/csironn.dir/nnai.o Building C object lib/nn/CMakeFiles/csironn.dir/nnpi.o Building C object lib/nn/CMakeFiles/csironn.dir/nncommon.o Linking C shared library libcsironn.dylib ld: Undefined symbols: _qh_countfacets _qh_findgood_all _qh_freeqhull _qh_memfreeshort _qh_new_qhull _qh_pointid _qh_qh /usr/bin/libtool: internal link edit command failed make[2]: *** [lib/nn/libcsironn.dylib.0.0.1] Error 1 make[1]: *** [lib/nn/CMakeFiles/csironn.dir/all] Error 2 make: *** [all] Error 2 So, it looks like I am still missing something, but if it is just qhull, I'm not sure that we want that to be a requirement to build plplot. -Hazen |
From: Rafael L. <rla...@us...> - 2006-07-05 22:06:40
|
Okay, here are my 2 cents in this thread. I will adopt the same style as Geoffrey, without quoting previous messages. Before posting in the list, Alan asked my opinion privately. I wrote to him: "If the current system is not broken, why fix it?" He insisted and enumerated all the potential advantages of CMake over the Autotools. Then I answered: "Show me the code, or get out of my way." Much to my pleasure, he started coding. I already told Alan that I am not going to be involved in the CMake effort, partly because I do not have the time to invest and also because I do not have the interest. However, if the CMake approach is proven to work and to provide the same functionality as the current system, I will be mostly happy, specially because the burden of being the Autotools guru will be removed from my shoulders. >From my previous experience with the cutover from the flat-build system to the current Autotools-based one, I think that the only way to get things accepted is by writing actual code. Long posts to the list trying to convince people that one approach is better than the other are not going to produce significant effects. I coded the whole AT approach on a side CVS branch and only when it was nearly completely functional then I had the courage to present it to the others and to start lobbying for its adoption. I propose that the CMake enthusiasts do the same. (I know, Alan, the CMake approach does not need a side CVS branch but, please, finish the code.) -- Rafael |
From: Robert S. <ro...@sc...> - 2006-07-06 09:59:38
|
Alan, My experience as the maintainer of a Linux distribution for embedded applications (http://www.pengutronix.de/software/ptxdist_en.html) is that most people who claim that there is something better than autotools start with enthusiasm, then note what immense ammount of necessary features really was in autotools and in the end extend their system to a point where it is almost as complex but incompatible to what all other people do. Just to mention some features which are an absolute must for our packets: - Support for cross compilation. I must be able to tell the build system that it should for example build with arm-softfloat-linux-gnu-gcc instead of gcc. - Support for cross compilation, taken that there are host tools involved. If you for example have a code generator in a packet, things like CC_FOR_BUILD are absolutely neede. Also, if you build a library and use it to link your code generator against it as well as for example your plotting samples, you have to build *two* libs, one for the development host (with gcc) and one for the target (with *-gcc). - The "build" architecture may have different properties than the "host" architecture. I want for example compile on x86_64 and generate code for powerpc-unknown-linux-gnu, or on ARM for systems with FPA vs. VFP floating point format. - Support for SYSROOT/DESTDIR. They are there for a reason. Packages must be able to determine independendly where to physically *install* plus where to actually *run*, and they may be different. And my experience also is that if you take the time and read through the autobook it is not as much magic any more as it was in the autoconf 2.13 era. It would really be a pitty if plplot would lose it's cross compilation possibilities. Just my 0.02 Euro. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 |
From: Rafael L. <rla...@us...> - 2006-07-06 11:54:11
|
* Robert Schwebel <ro...@sc...> [2006-07-06 11:59]: > And my experience also is that if you take the time and read through the > autobook it is not as much magic any more as it was in the autoconf 2.13 > era. It would really be a pitty if plplot would lose it's cross > compilation possibilities. This is my opinion too. I can hardly understand the argument that the current system is obscure or obfuscating. The previous flat-build approach also relied on autoconf for generating Makefile scraps (as Maurice pointed out in another post). The novelty introduced was the use of Automake to generate the Makefile.in's from the Makefile.am's. Automake introduce a layer of abstraction for yielding portable Makefiles. Learning Automake is not that complicated, in particular when a great documentation like the Autobook is available. That said, I have absolutely nothing against CMake (I maintain a CMake-based Debian package, called octaviz, and have even hacked some CMake code in the past). For the PLplot project, I am just waiting to see the CMake code. -- Rafael |
From: Alan W. I. <ir...@be...> - 2006-07-06 19:46:04
|
On 2006-07-06 05:53+0200 Werner Smekal wrote: > Since I always wanted to learn cmake, I'll try to help here, especially > on the Windows side. And I don't think it's a bad idea to work on cmake > file in parallel, it may work, and especially for Windows it might > provide a good solution. Thanks, Werner, for that offer to help with the cmake build system for PLplot. Here is the current status. I have just now used the am2cmake script (see http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/am2cmake) to use our existing Makefile.am files to determine crude first approximations to the required CMakeLists.txt files. These files will need considerable editing before they will actually work, but they are a start. I was careful not to disturb my previous work with the CMakeLists.txt files in the top-level directory and lib, lib/csa, and lib/nn. Thus, on my Debian stable box it is still possible to build and install shared libcsirocsa and libcsironn libraries, and to install the libcsiro documentation files using the cmake build system. Note, there is no testing (e.g., no tests similar to those in cf/csiro.ac are done) currently so there are some implicit assumptions about qhull, availability of libraries, etc., that don't interfere with the build on my platform (probably because I already have all the required software installed). However, I don't know what will happen to the libcsirocsa and libcsirnn build (especially for shared libraries) on a bare windows box so your testing will be most critical. Let me know what happens, and I would certainly be happy to accept patches from you or do some updates myself to help you get the build working properly for the libcsiro libraries for your bare windows box. The current top-level CMakeLists.txt file limits the build just to the lib tree. My future cmake plans are to expand the scope of the cmake build system in a logical progression through the remaining CMakeLists.txt files (i.e, in the directory order include, src, data, bindings, drivers, examples....) with my first emphasis being to make sure everything builds and installs on both my system and yours for the C binding and examples for the postscript driver using shared libraries and dynamic (plug-in/DLL) device drivers. Once, we have such a minimalist PLplot system working on my box and yours, then it should be straightforward to expand the scope of the cmake build system a lot further. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2006-07-11 06:38:00
|
On 2006-07-10 23:43-0400 hba...@ma... wrote: > Sorry for the last e-mail, as you clearly stated I need cmake version 2.4.2, > which I now have, and with which I get: > > iMac ~/Documents/OpenSource/PLplot/plplot-cvs : /usr/bin/cmake . > -- Check size of void* > -- Check size of void* - done > DEVICES_LIST = > DRIVERS_LIST = > CPACK_SOURCE_IGNORE_FILES = Makefile\\.in$;~$;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cvs.*/CVS/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cvs/bindings/;^/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-cvs/cf/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/debian/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/doc/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/drivers/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/examples/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/fonts/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/libltdl/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/old/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/pkgcfg/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/rpm/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/scripts/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/sys/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/test/;^/Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs/utils/ > -- Configuring done > -- Generating done > -- Build files have been written to: /Users/hbabcock/Documents/ > OpenSource/PLplot/plplot-cvs > > iMac ~/Documents/OpenSource/PLplot/plplot-cvs : make > Scanning dependencies of target csirocsa > Building C object lib/csa/CMakeFiles/csirocsa.dir/csa.o > Linking C shared library libcsirocsa.dylib > Scanning dependencies of target csironn > Building C object lib/nn/CMakeFiles/csironn.dir/delaunay.o > Building C object lib/nn/CMakeFiles/csironn.dir/hash.o > Building C object lib/nn/CMakeFiles/csironn.dir/istack.o > Building C object lib/nn/CMakeFiles/csironn.dir/lpi.o > Building C object lib/nn/CMakeFiles/csironn.dir/nnai.o > Building C object lib/nn/CMakeFiles/csironn.dir/nnpi.o > Building C object lib/nn/CMakeFiles/csironn.dir/nncommon.o > Linking C shared library libcsironn.dylib > ld: Undefined symbols: > _qh_countfacets > _qh_findgood_all > _qh_freeqhull > _qh_memfreeshort > _qh_new_qhull > _qh_pointid > _qh_qh > /usr/bin/libtool: internal link edit command failed > make[2]: *** [lib/nn/libcsironn.dylib.0.0.1] Error 1 > make[1]: *** [lib/nn/CMakeFiles/csironn.dir/all] Error 2 > make: *** [all] Error 2 > > So, it looks like I am still missing something, but if it is just qhull, I'm > not sure that we want that to be a requirement to build plplot. Here is what I suggest you do now that you have the correct version of cmake. (1) First create a clean PLplot source tree from CVS. I have no clue why libtool got involved above, but I am sure that is an artifact of mixing autotools and cmake builds, and a clean source tree should cure that. It may also cure the undefined symbol problems since without configuration of the csiro libraries, the default is nothing is configured so a lot of compilation is skipped and the build of what is left succeeds (at least on my system). (2) I run cmake in a separate build tree so the clean PLplot source tree always remains that way. From the separate build directory I invoke cmake as follows: cmake -DCMAKE_INSTALL_PREFIX=whatever_install_prefix_you_like -DPLD_ps=ON ../plplot_cmake where ../plplot_cmake is the clean build tree straight from cvs with nothing autotools-related run in it. (Note options for cmake are done with the -D command so I specified two cmake options above, one to specify CMAKE_INSTALL_PREFIX, and one to specify PLD_ps=ON which enables the ps device driver. For now, all devices are turned off by default to keep life simple so the above is the recommended way to enable one and only one simple device (i.e., one that does not depend on other libraries) for testing purposes now. I plan to expand back to the full device list soon. (3) to finish the build simply invoke make (as you have done above), then "make install" (which will make use of your install prefix above). Then you will want to hand-compile an example against this specially installed libplplot, then run the example to make sure the library actually works using -dev psc. Let me know whether using a clean source tree and separate build tree gives you a lot better result. If not, I am confident I can fix it since Mac OS X has been one of the supported CMake platforms for a long time now. Thanks very much for taking the trouble to test the cmake build system for PLplot on Mac OS X at this early stage of the project. If you want to understand a little more about what is going on with the PLplot CMakeLists.txt files and the module files in cmake/modules, I suggest reading the cmake tutorial (http://www.linuxjournal.com/article/6700). If you want to go further into more details, the cmake man page has lots of information. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |