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
__________________________
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
