Alan W. Irwin writes:
 > I think the explanation must be you are running into previously unknown
 > build issues because you are using the build system for situations
 > (platforms and library version sets) the rest of us don't have access
 > to. By definition that class of build-system bugs is hard for the rest of
 > us to replicate. Probably the best thing for you to do for this case is to
 > sit down and learn CMake deeply enough so you can fix these problems for
 > yourself.  That is actually quite easy to do, and I would be happy to help
 > you with that deeper CMake learning process if you run into anything you
 > cannot understand for yourself.

Alan W. Irwin writes:
 > CMake finds all the Tcl/Tk components using the logic in
 > 
 > $prefix/share/cmake-2.6/Modules/FindTCL.cmake where $prefix is the
 > installation prefix for the CMake install.  Where it searches is
 > controlled by the CMake variable TCLTK_POSSIBLE_LIB_PATHS.  It looks like
 > that list of paths includes references to the locations where tclsh and
 > wish are found.  From what you said, those should be on your PATH so it
 > appears something is going wrong with the CMake logic to relate library
 > location and header files to the location of tclsh and wish.  I suggest
 > you use the "message(...)  command on the components of
 > TCLTK_POSSIBLE_LIB_PATHS to see what the exact problem is.

I'll try to work this in.  Thanks for the suggestions and the pointers.

I do realize that the whole auto-configuration end of PLplot is a huge and
complex puzzle.  I worked on the old AC based system for years, and was
always getting e-mail from users complaining of this that or the other that
didn't work right.  So, I (and Maurice too) was only to happy to relinquish
that to others.  And I don't want to become the grumpy malcontent who is
always complaining about the build system, since I lived through years of
being on the receiving end of that kind of stuff, and I know only too well
how time consuming it is, and what dedication is required to make it work.  

And PLplot's auto-configuration support does get many many things right.  So
kudos to all who have worked so hard to get us from where we were in that
area, to where we are now.  It is for sure an tremendous improvement.

But the new system does seem brittle to me.  And I hope that somehow we can
get to a point where it behaves more resiliently to variation in the
underlying system.

As for learning cmake, yes I suppose I need to put more effort into that.
But that is actually one of my beef's with cmake:  It seems to take too much
effort to learn, given what it is... a utility for sniffing out the
characteristics of a system, and producing platform specific makefiles at the
end of the analysis.

Everytime I try to debug the cmake system, I find that almost everything I
try doesn't work, and if I read and read and read I eventually conclude that
what I first tried was just dumb.  Etc.  

Fundamentally, I just can't understand why anyone would invent a new language
*and* a new "library" for doing something as basic as what I might call
"system sleuthing".

Werner already pointed out that shell scripting could work, but that it
wouldn't work on Windows.  The multi-platform aspect of cmake is one of it's
strengths.  Acknowledged.

But I was ruminating on this today, and I think it's a key point that there
are plenty of "universal languages" out there.  Okay, maybe zsh isn't an
example.  While it isn't "unix bound" per se, I'm sure it could work in
Cygwin, the point that it isn't a normal component of a Windows system is
clear enough.

But what about Python?  If I was trying to build a system from scratch with
the same goals as cmake (as far as I understand that from the reading that I
have done about it), there is no way on earth I would've started off by
defining a new language.  Especially not a quirky, byzantine language.  Isn't
Python on every platform that cmake is on?  Wouldn't it make a lot more sense
to have used a "real language", with great data structures, and libraries,
and a module system, and all that?

I can't help thinking that by the time I figure out how to make cmake do what
I want, I could have accomplished the same thing in a fraction of the time if
it was written in a modern/popular system programming language (like Python,
though there are other languages of other names that could do the job too).

What is my point and why am I bothering to express this viewpoint on the
list?  Mainly that I think most people would find our build system less
daunting if it were written in something like Python instead of the
cmake-language.  If I spend time learning cmake, I only improve my skills
with the PLplot build system.  Nothing else I use (meaning, develop) uses
cmake.  But if I spend time learning more about Python, I can apply that to a
couple dozen projects I am also involved in besides the PLplot build system.

I think the same analysis would apply to many others.  Having the PLplot
build system written in cmake means many people will never invest the time to
become proficient at molding and shaping it.  Were the PLplot build system
"cmake-like", but written in Python, I bet a lot more people would find it
accessible. 

-Geoff

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to