From: phil r. <phi...@ya...> - 2013-03-17 12:47:25
|
Hi Alan Yes there are a number of pitfalls to watch out for, but there are probably a similar number of Linux pitfalls. Like when I tried to build plplot on my Ubuntu 11.04 (I think that's the right version number - the previous LTS) machine and the repositories didn't include a high enough version number of CMake or the fun of trying to distribute binaries between different Linux flavours. I had some colleagues recently at another institute and it took them around two years to convince the system admins to allow wxWidgets to be installed on the system so they couldn't run or build software I'd written or built - static linkage would have been a saviour there. Anyway I'm a fan of both and use both so I'm not going to start a who's got the best OS discussion ;-) Re the debug flag patch I haven't even had chance to look, nor am I really sure where to start. Actually it would be good to get some advice before I dive in. How do you go about debugging Cmake code? Is there any sort of debug tool or is it just a case of outputting variables to the console? In the Microsoft debugger I can stop C/C++ code at a break point and step through and see how variables are changed (Eclipse has similar functionality). I guess it's too much to ask for similar functionality with cmake, but if you have any useful debugging tips they'd be appreciated. Phil |
From: Alan W. I. <ir...@be...> - 2013-03-17 18:10:44
|
On 2013-03-17 05:47-0700 phil rosenberg wrote: > Hi Alan > Yes there are a number of pitfalls to watch out for, but there are probably a similar number of Linux pitfalls. Like when I tried to build plplot on my Ubuntu 11.04 (I think that's the right version number - the previous LTS) machine and the repositories didn't include a high enough version number of CMake or the fun of trying to distribute binaries between different Linux flavours. Yeah, sometimes distributions do not contain the version of software that you need, and binary incompatibility is always a problem between distributions. But I think the convenience of having most if not all of what you need already available in binary form for a particular distribution is a huge advantage for free software developers compared to the Windows situation where those developers are mostly on their own (unless they want to use the Cygwin distribution). Note, this is not a criticism of the platform, it is a criticism of free software developers for Windows all doing individual distribution work themselves rather than sharing that work in the self-organized manner that has been so effective in the Linux distribution case. Once a substantial number of non-commercial distributions (there are hundreds of those for Linux) got established for Windows, I am sure that some of those would turn into commercial distributions as well (just as historically happened for the Linux case). > I had some colleagues recently at another institute and it took them around two years to convince the system admins to allow wxWidgets to be installed on the system so they couldn't run or build software I'd written or built - static linkage would have been a saviour there. It's been a long time since I tried it, but my experience way back when was that static linking of external libraries was difficult on Linux. Quite a long time ago I tried to do that with PLplot as an experiment (using the -Bstatic linker option), and I eventually did get it to work, but library order is really important for the static linking case, and it took quite an effort to get that order figured out. I think the issue in that era was that Linux software package developers were not careful about the static linking case so their pkg-config configuration files had bugs (typically wrong order of libraries) for the static linking case. It would be interesting to try that experiment again now. I know that CMake developers are quite sensitive to static linking issues (because most CMake users are developers on the Windows platform where static linking is more important), and it is possible that software developers on Linux may now do a better job of configuring, e.g., pkg-config to deliver the correct static linking flags. > Anyway I'm a fan of both and use both so I'm not going to start a who's got the best OS discussion ;-) I use both Linux and Windows for testing of PLplot, but I recognize there would be a tonne of extra work required on my part to build all the libraries that various PLplot components depend on such as Qt4, pango/cairo, wxwidgets, octave, etc. I suspect I take the same approach for this case as other Windows PLplot developers and users do which is to ignore most of the possible dependencies. The result of those missing dependencies is that the PLplot build system automatically drops many of the PLplot bindings and device drivers. So the unfortunate side-effect of the lack of convenient Windows distributions of free software is PLplot tends to be much less powerful and less comprehensively tested on Windows compared to other platforms where installing the dependencies is so much simpler. > Re the debug flag patch I haven't even had chance to look, nor am I really sure where to start. Actually it would be good to get some advice before I dive in. How do you go about debugging Cmake code? Is there any sort of debug tool or is it just a case of outputting variables to the console? In the Microsoft debugger I can stop C/C++ code at a break point and step through and see how variables are changed (Eclipse has similar functionality). I guess it's too much to ask for similar functionality with CMake, but if you have any useful debugging tips they'd be appreciated. The first thing I suggest you do to debug CMake logic is simply to output CMake variables, as in the message(STATUS "variable = ${variable}") type of logic you will see throughout our build system. Also, there are various -debug, -trace, and -warn options for CMake documented by "cmake --help-full". The huge traffic on the CMake mailing list by Windows, Mac OS X, and Linux developers supports the idea that it is one of the most heavily used software build systems for those platforms. And there is no doubt that CMake-based build systems are quite useful and powerful. For example, the PLplot CMake-based build system solved a lot of problems that we had before with a mixture of autotools-based and Windows-specific build systems. So I encourage all those interested in PLplot development to develop CMake expertise, and I think such expertise will help developers to implement useful build systems for their other software projects as well. Anyhow, I would certainly be willing to help you increase your CMake expertise by responding to your questions (as above) about CMake. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |