RE: [Plplot-general] RE: patches,..(long)

[Geoffrey F. <fu...@ac...>]

Vince Darley writes:
 > >  > My changes are quite varied, so hopefully I'll be able to
 > >  > split them into a number of separate, independent patches.
 > >  > However, before I start that, I have a couple of questions:
 > >  > 
 > >  > (i) Does plplot support building any form of loadable
 > >  > extension for Tcl/Tk?  (i.e. a shared library Plxxx50.so which
 > >  > can be loaded into Tcl/Tk via 'load Plxxx50').
 > > 
 > > No, not at this time.  This is an obviously desirable improvment.
 > 
 > I'll probably try to create patches first which simply add
 > cross-platform Tk support to Plplot, and later work on adding
 > things like this (since I haven't compiled this code on unix for at
 > least 3 years, my makefiles are probably rather grotty).

By this to you mean owrk on your "tkwin" driver?

 > >  > (ii) Does plplot support cross-compilation (particularly for a cygwin
 > >  > hosted system to build linux executables)?
 > > 
 > > I don't know how to answer that question.  I've used cross tools
 > > before (for other things).  Ordinarily I am accustomed to just using a 
 > > particular gcc at a cerain path location, or mabye a stock gcc with a
 > > special -B or -V option to pick out the cross tool components.  To
 > > this extent--that is, just asuming your cross tool gcc/binutils are in 
 > > your path--it should "just work".  If you need some more specific kind 
 > > of support, please elaborate.
 > 
 > I mean so I can carry out a complete ./configure ; make on my windoze box,
 > yet have the executables generated work on whatever target I specify (e.g.
 > linux, solaris etc).  My simple tests didn't make it clear whether this
 > would really work or not (supposedly Tcl 8.x has a nice cross-compilation
 > ability, but I haven't really used that either).

Unless you have evidence to the contrary, it is my belief that this is 
simply a matter of chosing the gcc/binutils (putting them in your
path) which generate buidl products for the target environment.  The
only nit I can think of--is this what you're asking about?--is the
issue where configure runs little test compiles to try to
psychoanalyze the system.  In some cases it only tries to /compile/
things, but perhaps there are cases where it also tries to run the
resulting executable.  That would be a problem.  I don't know if there 
are cases where PLplot's configure script does or not.  If you find
that there are, I would be willing to try to help you develop ways to
circumvent this.

 > >  > (iii) Is there any configure/makefile support for non-unix based
 > >  > platforms?
 > > 
 > > Historically, Mac, OS/2, DOS/DJGPP and Amiga ports have all been done
 > > through a seperate makefile, independent of the unixoid configure at
 > > the top of the tree.  I've never gotten around to building on NT yet,
 > > but if I did, I would start by seeing if the existing configure script 
 > > would work okay on a cygwin platform.
 > 
 > I tried, and it doesn't look too good (not too bad either, though!).
 > Various problems arose (such as 'gcc not present', even though it is the
 > only compiler which is present).  I'll have to see what I can do. 

Well, the overall autoconf mechanism is certainly known to work on
cygwin.  All the GNU file and text utils that come with cygwin are
done that way for one thing.  Also, XEmacs works the same way (using
an autoconf-generated configure script).  So it definitely can be
done.  If there are shortcomings in PLplot's configure script, they
probably arise from the non-existence of NT cases in the various
switch blocks in plplot/cf/sysloc.cf and sysconf.cf.  I think it
shouldn't really be too hard to just visually scan that file and see
what is missing/wrong for NT.

I have an NT box here at Actel, I just never use it...  :-).

 > I'm not really sure of the best step forward from here!  I have a bunch of
 > code which has worked at varying times over the last 5 years on
 > Solaris/MacOS/Windows with various versions of Tk, and is currently in
 > constant use with Tk 8.3.1 on WinNT.  However I don't have access to a
 > linux machine I can actually do development on, so I don't really see a
 > sensible path to preparing useful patches without at least some help from
 > someone else: anyone willing to offer their services as a guinea pig?

My suggestions:

Get a cvs client for NT.  I have one on my little-used NT box here.  I 
forget where I got it.  I either compiled it myself, or perhaps I got
it from one of the various NT unix-goods stockpile sites.  There is
somebody who has XEmacs, X11, etc, maybe I got it from there.

Anyway, once you have your NT cvs client, you can do an anonymous
checkout of the plplot sources from cvs.plplot.org, straight to your
NT box.  Hack that code to your liking, then run cvs diff, and send in 
the patches.

In this mechanical respect, I don't think working on NT is much
different from unix.  I have certainly been able to successfully make
similar fixes to Actel code from my NT box here.

 > One approach I'm considering is that the core pl code should be compiled
 > into a shared library with the existing makefiles, and that the tcl/tk
 > dependent stuff should use it's own makefiles using the 'TEA' (Tcl
 > Extension Architecture) framework developed by the Tcl community which
 > should make it easy to turn 'C-code + pllibs + Tcl installation' into
 > something which will compile under any platform where Tcl/Tk works.
 > Perhaps this should be step 5, not step 1 however.  Advice appreciated!

I am definitely in favor of a TEA-based approach.  As it happens, I
downloaded the TEA docs that I could find just last week, and was
starting to look into that myself before I became distracted.  Not
sure when I could return to it myself at this point, but I definitely
agree that this is the desired plan of attack.

-- 
Geoffrey Furnish            Actel Corporation        fu...@ac...
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski