Hi all,
I've injected the work formerly done on the python branch, onto svn trunk
tip.
I've done a little messing around with cmake, so I would appreciate it if
people could look over bindings/python/CMakeLists.txt in particular. One
concern I have is that someone might disable Tcl/Tk, but enable python. In
that case, it seems to me the python widget module should be built without
linking to the Tcl/Tk stuff, and without using the TCL_INCLUDE dir. But I'm
not able to author that in cmake-ese yet, so if someone could tweak that, I'd
be really appreciative.
If you build in a way that allows Tcl/Tk and Python to all be found and
activated, you'll now have some new options in the Python code. One way to
see this would be something along the lines of:
cd <wherever>/plplot/examples/python
env PYTHONPATH=$CMAKE_BUILD_PREFIX/lib64/python2.6/site-pakages \
python pytkdemo
You'll notice that the plframe appears right along with other Tk widgets in
this teeny little Python/Tk "application" which is intended just to show off
the various demo programs (the python versions thereof).
The other thing worth discussing is just to draw attention to the fact that
in the past I had trouble with how the python modules are being linked. I
haven't gotten as far as reinvestigating that, so I'll post more on it
later. But in the past I found that explicitly linking to PYTHON_LIBRARIES
caused problems for some applications. So, that's an open issue that I'll be
reporting more on later, after I look into it again.
There is still much to do. Plframe.py is suffering badly from years of
atrophy. I'll see what I can do.
Please let me know of any problems. I'll try to be watching our e-mail lists
a little more carefully over the coming days, in case anyone is screaming for
releif from my unclueful ways.
Oh, btw, one more thing. Why did I say "merged"? Because it turns out that
git-svn is far lamer than I previously knew. I guess it's constrained by
what the svn protocol supports, but I had certainly hoped for more. So I
think I said before that I didn't personally like git-svn, and didn't
consider it really a very good way for the git-inclined to deal with PLplot,
and I am much more convinced of that now after trying to work with it a bit.
I will continue working to document some git work-flow cases, or scenarios,
so that people can dip their toes in, if inclined. But git-svn is really
just a wrapper around svn which gives it a "git-ish" interface. But it's not
really git in the way that git is git, if you see what I mean. I guess what
I'm trying to say here is no one should conclude that experience with git-svn
gives much of a picture of a git work flow. git-svn is very slow, clunky,
and merge-iimpaired, compared to git. So it will be hard to develop much
clarity of expectation of what a git workflow would be like, from using
git-svn.
As I get further along in my documentation of the git work-flow, I'll try to
include some example of "bare git". Those will help people to get a better
taste of what a git-hosted project is really like. But it will be
considerably harder to feed work done in such situations back into svn.
Personally, I could live with git-svn being slow, if it just supported a more
git-like work flow. But I'm not prepared to go working on git-svn itself at
this time. Way too much else to do.
Oh, one more really last thing. I haven't gotten around to trying out Alan's
proposal for plplot-mode. But I did pull down and install cmake-mode.el.
Hoping to keep our style as similar as possible, despite several different
languages being in play in the PLplot project, I changed cmake-mode.el to use
4 (rather than 2) for the tab stop setting. It seemed from our former
discussion about C style, that people were all good with 4 char indentation
levels, so I plan to use that also in my cmake-mode.el (and today's commits
reflect that). Does anyone know why "describe-mode" doesn't seem to have
much to say about cmake-mode? Skimming the file, you'd think there would be
a number of functions bound to keys, but apparently not. Seems strange. Am
I missing something that anyone else has found?
Cheers,
--
Geoff
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
