On Fri, Jul 2, 2010 at 1:35 AM, Arjen Markus <arjen.mar...@deltares.nl> wrote:
> Hi Puneet,
>
> congratulations!
>
> On 2010-07-02 04:23, P Kishor wrote:
>>
>> hot damn!
>>
>> DRIVERS_LIST: gd;mem;null;ps;svg;xfig;xwin
>> DEVICES_LIST: gif;jpeg;png;mem;null;ps;svg;xfig;xwin
>>
>> So, what did I do? Scientifically, I can't report exactly what I did
>> that caused the above to build, but the general drift is --
>>
>
> ...
>>
>> So, I guessed cmake needed a nudge, and since I had rebuilt most
>> everything, I ran cmake again, once again with my kitchen sink of
>> options.
>>
>> This time... it worked!
>>
>> It is still not picking up Cairo and AGG, but heck, I am going to
>> crack a beer and celebrate for now. Enough of installation crap. Time
>> to actually make some pretty pictures.
>>
>> Thanks all. Couldn't have done without you all. Go get a beer. Grill a
>> tofu. Think of all the good things you have done.
>>
>
> Glad you were able to sort it out - is there any generic lesson we
> can learn from this? Advice on how to check for a properly built set of
> libraries?
>
..
Actually, I am not compilation-savvy enough to answer *how* to check
for the correct libraries, but I am not battle-scarred enough to say
that one *needs* to check for the correct libraries, but here are a
few things that come to my mind --
Some of my issues were self-inflicted -- some libraries, even though I
had installed them myself, had linked against some of Apple's older
X11R6 stuff. So, they were new libraries with old functionality. Some
libraries, even though I had installed them myself, had been built
when I had Leopard (Mac OS X 10.5) on my computer. About 2 months ago
I upgraded my laptop to Snow Leopard (Mac OS X 10.6), so now I keep on
discovering stuff that was compiled for i386, not x_86_64. In cmake
(and in the underlying ccmake) there seems to be a place to specify
"architectures" but I wasn't able to get anything other than i386. I
almost expected to have an option called 'x_86_64'.
Marius's advice -- use otool to figure out what has been compiled in
the library -- is priceless. From man otool
"The otool command displays specified parts of object files or libraries."
That showed me that my libgd, even though it was brand new(ish), it
didn't have the proper jpeg/png code.
So, an install on a clean machine would most likely be extremely easy.
But a clean machine, other than one just taken out from packaging, is
probably an extremely unlikely occurrence.
I understand your logic for using cmake (cross-platform
compatibility), but I have found configure to be the easiest to use. I
have used it so many times that if I come across a tool that doesn't
use configure, I instinctively brace my neck for a whiplash.
If I could specify to cmake exactly which libraries to use, that would
be great. If I could type 'cmake --help' and see exactly all the
options specific to the software I am installing, I wouldn't have to
bop between my computer and miscdebris.net to double-check on the
allowable options. At the least, all options could be include in the
README/INSTALL files. Right now, iirc, there is only the note that one
should go to the wiki to see what the options are.
What would be really cool would be to display a tree view of all the
libraries that the software will be compiled against, and all their
dependencies recursively. Probably very difficult to pull off, but
that would be cool. Something like --
======================================
Your build of PLplot will be compiled against
- /usr/local/lib/libgd.dylib
- /usr/local/lib/libpng.dylib
- /usr/local/lib/libfontconfig...
..
and so on
The PLplot header files will be stored in
- /usr/local/include/plplot
The PLplot libraries will be stored in
- /usr/local/lib/plplot5.9.6/
======================================
and so on. To some extent, the cmake output already states the above,
but it is a mess from the readability point of view. The best example
of config/build output redone really well is Miyagawa's cpanminus. The
stock cpan installation (in Perl world) spews out pages after pages of
"nonsense" in a rapid-fast manner (nonsense, from the point of view of
a not too savvy user such as me). cpanm suppressed all that crap,
printing out only the most minimal of messages, and only to show the
progress (or failure). Rest gets written to a build.log automatically.
Even saving the user from doing a >& make.out was a great step forward
(besides, I do want to see some progress, not complete silence).
Finally, cross-platform compatibility is a laudable goal, but nothing
beats instructions specific to different os/cpu combinations. From
those who have successfully mastered building PLplot on Mac OS X Snow
Leopard, an easy to understand write-up would be great. Note, while I
have build PLplot now, I have neither achieved complete success (I
still haven't been able to compile it against cairo and AGG -- more on
that in a separate email), nor have I mastered it.
Phew! I hope some of the above helps in improving the cmake tool.
Last note: Having a great user/support community would be invaluable.
Wait! PLplot already has that!
:-)
--
Puneet Kishor
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general
