plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] KCC flags

[Alan W. I. <ir...@be...>]

On Thu, 26 Dec 2002, Maurice LeBrun wrote:

> Is cf/sysloc.in the *only* file under cf/ currently in use?

Nothing (including sysloc.in) is currently used from the cf directory.  I
did copy sysloc.in from that directory to the top level, and then stripped
some stuff I thought was unneeded from it.

You should be able to get back what you need by doing a diff between the two
to see what has been added and what has been stripped from the top level
version compared to the cf version of sysloc.in.  Then it should be a simple
matter to add back whatever extra is needed to the top level version.
However, this might not be necessary, see next paragraph.

One thing that puzzles me about your recent ".lo" comments is that autotools
are supposed to work fine with cc on solaris (see PLATFORMS in the
autobook).  So I don't see why ".lo" is bothering cc.  Also, from a google
search, there have been commits to the libtool tree to deal specifically
with KCC.  So I started wondering if there was something simple (a flag or
macro) that will make KCC work smoothly.  I just looked at info autoconf,
and indeed there is a compiler list you can give the AC_PROG_CXX and
AC_PROG_CC macros, and KCC is one of those compilers.  Perhaps specifying a
compiler list to those macros that includes KCC is what you should be doing.

Another thing worth trying on solaris is cc rather than KCC to see whether
autotools does work as claimed with pure cc.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] KCC flags

[Maurice L. <mj...@ga...>]

Maurice LeBrun writes:
 > Are the --with-profile, --with-debug, etc, options even being honored any more?

I guess I'll answer my own question: no.

The following variables (set by their corresponding --with-<xxx> command line
switch) were used to modify the build parameters in a reasonably
system-independent way.

with_debug	debug compile
with_opt	optimized compile
with_warn	full warnings turned on (default: off)
with_profile	add profiling code

along with checks as necessary (e.g. profiling needs static library &
debugging).  This stuff was all in cf/sysconf.in, which is no longer
being included.

Is cf/sysloc.in the *only* file under cf/ currently in use?

I guess I'll put it on my list to add this functionality back in, as I do have
need of it at times.  Sure, one can override CFLAGS or whatever to do what
you want, but then you have to remember what flags are appropriate for the
system you're on, every time you do it.  Much better to put it in once, then
never have to think about it again.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] KCC flags

[Maurice L. <mj...@ga...>]

Maurice LeBrun writes:
 > Uh oh.. KCC always uses the vendor compiler as its backend.  And in this case
 > it looks like Sun cc doesn't support other than ".o" for the suffix.  This
 > could potentially be a real problem for Geoff & I.

BTW:

$ uname -a
SunOS xxxxx 5.7 ...

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] KCC flags

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > On Thu, 26 Dec 2002, Maurice LeBrun wrote:
 > 
 > > On another note, I need to modify the command line args used by the compiler
 > > or linker.  Although I've made progress, so far I still haven't gotten a
 > > completely successful build on either: Solaris, OSF1, or IRIX.  As for the
 > > first two, the build is trying to pass the "-fPIC" option to the KCC compiler
 > > which isn't supported.  So I need to get rid of that, or change it to +KPIC.
 > > I'm reading through the AM info pages now, what a pain.
 > >
 > > As for IRIX, I need to pass "-64 -mips4" somehow.  This at least I know I can
 > > do in principle, probably by using flags like I did before:
 > >
 > > USER_FLAGS_CXX:	add these to CXXFLAGS
 > > USER_FLAGS_CC:	add these to CCFLAGS

(oops, typo, the latter should just be 1 "C")

 > Can you just set LDFLAGS to +KPIC and CXXFLAGS and CFLAGS to "-64 -mips4" in
 > the environment before you configure?  

Potentially, yes.  However my old configure script modified CXXFLAGS and
CFLAGS according to the various command line flags: --with-debug,
--with-profile, --with-opt.  So I used the "USER_FLAGS.." variables to
only add to that as needed for the vendor compiler, architecture, etc.

In other words, setting USER_FLAGS_CXX means: I trust the CXXFLAGS the
configure script is giving me, just add these.  We can still set CXXFLAGS
directly, but then we're giving up control through the usual command-line
flags.  That's what much of the previous logic in sysconf.in was for.

Are the --with-profile, --with-debug, etc, options even being honored any more?

 > I believe autotools tries really hard
 > to allow the user to override that way.  

Yeah I noticed that autotools uses AM_CXXFLAGS, etc, instead of CXXFLAGS, etc,
passing the latter along unmodified.

 > Of course, this suggestion will
 > only work if the KCC compiler only warns about the -fPIC flag rather than
 > aborting completely if it encounters it.  If this works with environment
 > variables, then it will be easier to proceed to automating it.

I just realized I misread the build output.  Indeed, KCC is only warning about
the -fPIC flag, so no need to do anything about it just yet.  The real problem
is a lot more sinister:

/bin/bash ../../libtool --mode=compile KCC -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include  -I../../libltdl   +K2 -O2 -c -o plstream.lo `test -f 'plstream.cc' || echo './'`plstream.cc
mkdir .libs
KCC -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../libltdl +K2 -O2 -c plstream.cc  -fPIC -DPIC -o .libs/plstream.lo
KCC: Option -fPIC not recognized.
cc: illegal suffix of output filename
make[2]: *** [plstream.lo] Error 1

Uh oh.. KCC always uses the vendor compiler as its backend.  And in this case
it looks like Sun cc doesn't support other than ".o" for the suffix.  This
could potentially be a real problem for Geoff & I.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

[Plplot-devel] KCC flags

[Alan W. I. <ir...@be...>]

On Thu, 26 Dec 2002, Maurice LeBrun wrote:

> On another note, I need to modify the command line args used by the compiler
> or linker.  Although I've made progress, so far I still haven't gotten a
> completely successful build on either: Solaris, OSF1, or IRIX.  As for the
> first two, the build is trying to pass the "-fPIC" option to the KCC compiler
> which isn't supported.  So I need to get rid of that, or change it to +KPIC.
> I'm reading through the AM info pages now, what a pain.
>
> As for IRIX, I need to pass "-64 -mips4" somehow.  This at least I know I can
> do in principle, probably by using flags like I did before:
>
> USER_FLAGS_CXX:	add these to CXXFLAGS
> USER_FLAGS_CC:	add these to CCFLAGS

Can you just set LDFLAGS to +KPIC and CXXFLAGS and CFLAGS to "-64 -mips4" in
the environment before you configure?  I believe autotools tries really hard
to allow the user to override that way.  Of course, this suggestion will
only work if the KCC compiler only warns about the -fPIC flag rather than
aborting completely if it encounters it.  If this works with environment
variables, then it will be easier to proceed to automating it.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] problem with --disable-cxx

[Maurice L. <mj...@ga...>]

Maurice LeBrun writes:
 > Alan W. Irwin writes:
 >  > On Thu, 26 Dec 2002, Maurice LeBrun wrote:
 >  > 
 >  > > ged$ ./configure --prefix=$HOME/tools --enable-dyndrivers --disable-cxx
 >  > > ...
 >  > > configure: error: conditional "am__fastdepCXX" was never defined.
 >  > > Usually this means the macro was only invoked conditionally.

I think I've tracked this down to some lunacy being done inside the
AC_PROG_CXX macro, as you might expect.  Using AC_* macros inside of
conditionals has bitten me on the butt before.. doesn't anyone else use
alternate paths of logic in configure.ac (or .in) files?  Jeez.

I moved AC_PROG_CXX outside of the test, i.e.

if test "$enable_cxx" = yes; then
  ...
fi
AC_PROG_CXX

and now it works fine.  I think the reason it wasn't seen by Alan is that it's
from a relatively new change and I'm working with the latest version.

I don't suppose it really matters if we check for the presence of a C++
compiler despite $enable_cxx being set to "no", except for the possibility of
it being confusing to the user.  But now there's so much configure output that
you have to look closely to even see it anyway :/.  So I'm going to leave it
as-is.  Those wanting to reproduce the bug should install the packages I'm
using and move AC_PROG_CXX back up one line, then configure with cxx disabled.

Grumble..

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] problem with --disable-cxx

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > On Thu, 26 Dec 2002, Maurice LeBrun wrote:
 > 
 > > ged$ ./configure --prefix=$HOME/tools --enable-dyndrivers --disable-cxx
 > >
 > > gives:
 > >
 > > ...
 > > checking for IceConnectionNumber in -lICE... yes
 > > checking for dynamic drivers... null pbm plmeta ps pstex tk xwin
 > > creating drivers/drivers.db
 > > configure: error: conditional "am__fastdepCXX" was never defined.
 > > Usually this means the macro was only invoked conditionally.
 > >
 > > and that's where it stops.
 > 
 > I cannot confirm the problem here;
 > 
 > ./configure --prefix=/usr/local/plplot_at --enable-dyndrivers --disable-cxx
 > 
 > works fine here.  However, I have a lot more dynamic drivers than you by
 > default so I suspect you have a special configuration file turning some of
 > them off.  Could that file be the source of the problem?  Try ./configure
 > without it.
 > 
 > Another thought....  I did 'make distclean' and ./bootstrap.sh before the
 > configure.  Is something from an old configure interfering with your new
 > configure?

Nope, I removed my ~/config/cf_plplot.in and tried it from a freshly checked
out tree, and it still fails at the same place.  Am investigating.

On another note, I need to modify the command line args used by the compiler
or linker.  Although I've made progress, so far I still haven't gotten a
completely successful build on either: Solaris, OSF1, or IRIX.  As for the
first two, the build is trying to pass the "-fPIC" option to the KCC compiler
which isn't supported.  So I need to get rid of that, or change it to +KPIC.
I'm reading through the AM info pages now, what a pain.

As for IRIX, I need to pass "-64 -mips4" somehow.  This at least I know I can
do in principle, probably by using flags like I did before:

USER_FLAGS_CXX:	add these to CXXFLAGS
USER_FLAGS_CC:	add these to CCFLAGS

and so on.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] problem with --disable-cxx

[Alan W. I. <ir...@be...>]

On Thu, 26 Dec 2002, Maurice LeBrun wrote:

> ged$ ./configure --prefix=$HOME/tools --enable-dyndrivers --disable-cxx
>
> gives:
>
> ...
> checking for IceConnectionNumber in -lICE... yes
> checking for dynamic drivers... null pbm plmeta ps pstex tk xwin
> creating drivers/drivers.db
> configure: error: conditional "am__fastdepCXX" was never defined.
> Usually this means the macro was only invoked conditionally.
>
> and that's where it stops.

I cannot confirm the problem here;

./configure --prefix=/usr/local/plplot_at --enable-dyndrivers --disable-cxx

works fine here.  However, I have a lot more dynamic drivers than you by
default so I suspect you have a special configuration file turning some of
them off.  Could that file be the source of the problem?  Try ./configure
without it.

Another thought....  I did 'make distclean' and ./bootstrap.sh before the
configure.  Is something from an old configure interfering with your new
configure?

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-devel] problem with --disable-cxx

[Maurice L. <mj...@ga...>]

ged$ ./configure --prefix=$HOME/tools --enable-dyndrivers --disable-cxx

gives:

...
checking for IceConnectionNumber in -lICE... yes
checking for dynamic drivers... null pbm plmeta ps pstex tk xwin 
creating drivers/drivers.db
configure: error: conditional "am__fastdepCXX" was never defined.
Usually this means the macro was only invoked conditionally.

and that's where it stops.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] prova.py example

[Alan W. I. <ir...@be...>]

On Wed, 25 Dec 2002, Maurice LeBrun wrote:

> OK, I found it on my RH7.3 system in the python1.5 install.  But
> unfortunately, not under python2.2.  Probably the biggest flaw of RH7.3 in my
> book is this split python distribution.

I agree 100 per cent.  When making the RH 7.3 rpm, I got around the RH split
python problem by forcing a number of variables for plplot-5.1.0.  I haven't
tried this for CVS HEAD, but I believe it should work since I copied most of
plplot/cf/sysloc.in to plplot/sysloc.in where these variables should
override the python search that ordinarily fails completely on RH 7.3
because of their split system.

PY_VERSION=python -c 'import sys ; print sys.version[0:3]'
export
PYTHON_INC_DIR=/usr/include/python${PY_VERSION}/
export PYTHON_MOD_DIR=/usr/lib/python${PY_VERSION}/
export PYTHON_CFG_DIR=${PYTHON_MOD_DIR}/config
export PYTHON_NUM_DIR=${PYTHON_INC_DIR}/Numeric/
export PYTHON_MACH_DIR=${PYTHON_MOD_DIR}/site-packages
export PYTHON_DIR=${PYTHON_MACH_DIR}
./configure --prefix=/usr --with-double --enable-dyndrivers --enable-gnome
--ena
ble-ntk --disable-linuxvga

See plplot/rpm/plplot_redhat7.3.spec.

Of course it is just a workaround, but it may be a necessary one since I am
not sure we should expect sysloc.in to be able to deal with a split python
version system.

Hope this helps.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] prova.py example

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > On Wed, 25 Dec 2002, Maurice LeBrun wrote:
 > 
 > > BTW does this work for anyone?
 > >
 > > ged$ ./prova.py
 > > Traceback (most recent call last):
 > >   File "./prova.py", line 9, in ?
 > >     from qt import *
 > > ImportError: No module named qt
 > >
 > > I followed the prescription for finding libqt but it didn't work.
 > >
 > > ged$ echo $LD_LIBRARY_PATH
 > > .:/home/mjl/gts/lib:/usr/lib/qt-3.0.3/lib
 > >
 > > ged$ ll -L /usr/lib/qt-3.0.3/lib/libqt.so
 > > -rwxr-xr-x    1 root     root      7644546 Apr 16  2002 /usr/lib/qt-3.0.3/lib/libqt.so
 > 
 > Yes, works for me.  qt refers to the python module
 > (/usr/lib/python2.1/site-packages/qt.py(o)), not the qt library.  The module
 > is in the python-pyqt package on Debian.  I don't know what that package is
 > named on RedHat, but you should be able to find it using rpmfind on qt.py.
 > 
 > You will also need libsip.

OK, I found it on my RH7.3 system in the python1.5 install.  But
unfortunately, not under python2.2.  Probably the biggest flaw of RH7.3 in my
book is this split python distribution.  There's no rpm specifically for
RH7.3 & python2.2 either, so instead of installing from source I'm trying
the default python1.5.

There's a problem with the configuration under bindings/python.  It locates
/usr/bin/python which is 1.5 but otherwise gets the 2.2 libraries which
of course won't work.  From bindings/python/Makefile:

PYTHON = /usr/bin/python
PYTHON_CFG_DIR = /usr/lib/python2.2/config
PYTHON_DIR = /home/mjl/tools/lib/python2.2/site-packages
PYTHON_EXEC_PREFIX = ${exec_prefix}
PYTHON_INC_DIR = /usr/include/python2.2
PYTHON_INSTDIR = lib/python2.2/site-packages
PYTHON_MACH_DIR = /usr/lib/python2.2/site-packages
PYTHON_MOD_DIR = /usr/lib/python2.2
PYTHON_NUM_DIR = /usr/include/python2.2/Numeric
PYTHON_PLATFORM = linux-i386
PYTHON_PREFIX = ${prefix}
PYTHON_VERSION = 1.5

Ugh.  I'll look into it a little more but am about out of time to spend on
this problem.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] documentation needs updating

[Alan W. I. <ir...@be...>]

On Tue, 24 Dec 2002, Maurice LeBrun wrote:

> Someone :) should update:
>
> examples/tcl/README.tcldemos
>
> give yet another way (script file) to invoke demo, also modify text
> about unreliable finding of *.tcl files since that should be fixed now.
>
> examples/tk/README.tkdemos
>
> excise text about running from tmp/ dir.

Somone has just done this....;-)

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] PLplot, python, and SWIG

[Alan W. I. <ir...@be...>]

On Wed, 25 Dec 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > So in light of that extra information, what do you think of just putting a
>  > comment in the Makefile.am where swig is invoked and letting it go at that
>  > (assuming I don't have time to make 1.3.17 work)?  If I use the right
>  > number of # characters in the front of such a comment it propagates to
>  > Makefile.in and Makefile as well.
>
> I think it's needed there and in the README.pythondemos as well, since the
> latter is where people trying to run the python demos will look.
>

I have updated bindings/python/README.pythonbuild to reflect the current
swig situation. I have also updated examples/python/README.pythondemos to
refer to README.pythonbuild and also reflect the current install situation
as well as what is required to get the prova.py example to work.

I have also updated bindings/python/Makefile.am to a style where the double
and single-precision forms of the interface can be pre-generated.  (I
thought I had this before, but it wasn't really the case.) In the same file
I have also documented the required swig version as well.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-devel] prova.py example

[Alan W. I. <ir...@be...>]

On Wed, 25 Dec 2002, Maurice LeBrun wrote:

> BTW does this work for anyone?
>
> ged$ ./prova.py
> Traceback (most recent call last):
>   File "./prova.py", line 9, in ?
>     from qt import *
> ImportError: No module named qt
>
> I followed the prescription for finding libqt but it didn't work.
>
> ged$ echo $LD_LIBRARY_PATH
> .:/home/mjl/gts/lib:/usr/lib/qt-3.0.3/lib
>
> ged$ ll -L /usr/lib/qt-3.0.3/lib/libqt.so
> -rwxr-xr-x    1 root     root      7644546 Apr 16  2002 /usr/lib/qt-3.0.3/lib/libqt.so

Yes, works for me.  qt refers to the python module
(/usr/lib/python2.1/site-packages/qt.py(o)), not the qt library.  The module
is in the python-pyqt package on Debian.  I don't know what that package is
named on RedHat, but you should be able to find it using rpmfind on qt.py.

You will also need libsip.

Good luck, and Merry Christmas!

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] PLplot, python, and SWIG

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > So in light of that extra information, what do you think of just putting a
 > comment in the Makefile.am where swig is invoked and letting it go at that
 > (assuming I don't have time to make 1.3.17 work)?  If I use the right
 > number of # characters in the front of such a comment it propagates to
 > Makefile.in and Makefile as well.

I think it's needed there and in the README.pythondemos as well, since the
latter is where people trying to run the python demos will look.

BTW does this work for anyone?

ged$ ./prova.py 
Traceback (most recent call last):
  File "./prova.py", line 9, in ?
    from qt import *
ImportError: No module named qt

I followed the prescription for finding libqt but it didn't work.

ged$ echo $LD_LIBRARY_PATH
.:/home/mjl/gts/lib:/usr/lib/qt-3.0.3/lib

ged$ ll -L /usr/lib/qt-3.0.3/lib/libqt.so
-rwxr-xr-x    1 root     root      7644546 Apr 16  2002 /usr/lib/qt-3.0.3/lib/libqt.so

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] PLplot, python, and SWIG

[Alan W. I. <ir...@be...>]

On Tue, 24 Dec 2002, Maurice LeBrun wrote:

> In my tests from last Sept, I found that swig versions:
>
>     1.3.11 - 1.3.13
>
> were the only ones that worked with the plplot python wrapper code.
> Specifically:
>
>     1.3.14 & 1.3.15
>
> did NOT work, due to the following change:
>
>  > < #define SWIG_init    initplplotc
>  > < #define SWIG_name    "plplotc"
>  >
>  > > #define SWIG_init    init_plplotc
>  > > #define SWIG_name    "_plplotc"
>  >
>  > The latter ones are those generated by swig 1.3.14.  Ugh.
>
> Has this been fixed?  I don't recall seeing cvs commits for it but could've
> missed it.

Not fixed.  I may get to it in the next few days, but I am not sure I will
have the time.  I am playing with swig-1.3.17 at the moment, but the focus
is on java.  There *might* be a chance to produce a complete plplot API
under java which is an exciting possibility.  I have already gotten it to
work well enough so I can produce our simplest example (x10.java), but I am
still on pretty steep parts of both the swig and java learning curves so it
is not clear how long this will take.  It is possible I could get it done
before January, but otherwise I will go with the present hand-crafted but
fairly incomplete java interface we have now for the release, and try again
with swig and java after the release.

>
> BTW the latest swig is up to 1.3.17.  If we do go to release with it working
> only with swig 1.3.11 - 1.3.13, this needs to be very prominently stated
> *somewhere*.

I am willing to state that somewhere, but it may not be necessary (or may
not need to be very prominent) since it is only going to affect CVS
developers as now.  The tarball will have the swig-generated interface file
in it already so no tarball (or rpm or deb) user will require swig at all.

So in light of that extra information, what do you think of just putting a
comment in the Makefile.am where swig is invoked and letting it go at that
(assuming I don't have time to make 1.3.17 work)?  If I use the right
number of # characters in the front of such a comment it propagates to
Makefile.in and Makefile as well.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-devel] PLplot, python, and SWIG

[Maurice L. <mj...@ga...>]

In my tests from last Sept, I found that swig versions:

    1.3.11 - 1.3.13

were the only ones that worked with the plplot python wrapper code.
Specifically:

    1.3.14 & 1.3.15

did NOT work, due to the following change:

 > < #define SWIG_init    initplplotc 
 > < #define SWIG_name    "plplotc" 
 >  
 > > #define SWIG_init    init_plplotc 
 > > #define SWIG_name    "_plplotc" 
 >  
 > The latter ones are those generated by swig 1.3.14.  Ugh. 
 
Has this been fixed?  I don't recall seeing cvs commits for it but could've
missed it.

BTW the latest swig is up to 1.3.17.  If we do go to release with it working
only with swig 1.3.11 - 1.3.13, this needs to be very prominently stated
*somewhere*.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

[Plplot-devel] documentation needs updating

[Maurice L. <mj...@ga...>]

Someone :) should update:

examples/tcl/README.tcldemos

give yet another way (script file) to invoke demo, also modify text
about unreliable finding of *.tcl files since that should be fixed now.

examples/tk/README.tkdemos

excise text about running from tmp/ dir.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] proper include guards for plConfig.h

[Maurice L. <mj...@ga...>]

Maurice LeBrun writes:
 > Although I fixed the include guards in acconfig.h, because of the way
 > autoheader works they're still broken in include/plConfig.h{,.in}.  Anyone
 > know of a way to properly handle these?
 > 
 > (i.e. the #endif should be the very last statement to protect against
 > multiple inclusions)

Sigh..

We now have several new problems with the autoconf-generated header files
in addition to the old one (#1 below).

1. User codes that include plplot.h really shouldn't necessarily be exposed to
all the details of the configuration process.  I looked into this issue
previously but never got back to it.  I think all configuration related
defines should default to private, i.e. not be visible when including
plplot.h.  The public ones would only be those we specifically decide to
export like PACKAGE, VERSION, PL_DOUBLE, etc.  The problem has gotten worse
than the last time I looked at it because of many new autoconf tests.  I
really don't like the idea of injecting all these defines into the global
namespace.

2. Include guards on plConfig.h are broken.

3. acconfig.h now has device defines in addition to the more customary
configuration defines, so these device defines now appear in *both* plDevs.h
and plConfig.h, which is superfluous.  Maybe not harmful, at least.

4. autoheader's obnoxious warning, and the real possibility the "file
template" style will go away some day.

On the severity scale, 3 & 4 are mostly just irritants, but could probably be
made to go away easily enough in the course of fixing numbers 1 & 2.

For the solution, I'm envisioning 3 include files:
 plConfigP.h plConfig.h plDevs.h

none of which are autoconf-generated.  These are the only files that may be
included by plplot codes, and each has include guards.  Each include an
autoconf-generated header file with a specific subset of the entire set
of defines according to the following rule set:

 - the default set goes to the file included by plConfigP.h
 - the publicly-exported set goes to the file included by plConfig.h
 - the device set goes to the file included by plDevs.h

Still need names for all these autoconf-generated headers.  Use 3rd
arg of AC_DEFINE* to create assuming the autoconf API will cooperate.
Need to find out what autoconf's support this feature.

This will address all 4 points.

I may get the time to work on this before the release but am mostly writing
all this down as a reminder as to what should eventually be fixed.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] Bug in library: Segmentation fault if "Q" hit.

[Maurice L. <mj...@ga...>]

Fixed.
-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] more on Makefile.examples

[Alan W. I. <ir...@be...>]

On Tue, 24 Dec 2002, Maurice LeBrun wrote:

>  - it'd be a lot better if in the examples dirs, the makefile was named
> "Makefile" instead of "Makefile.examples".  Is this straightforward

There is a name clash in the build area since automake and configure
together process Makefile.am ==> Makefile.in ==> Makefile.  Furthermore,
all the standard examples for automake that I have seen use exactly the
same file name in the build and install areas.  To avoid the name clash
you therefore need a subdirectory.  I have implemented, tested, and committed
that.  I agree it is much better to have Makefile in the installed examples
tree rather than Makefile.examples.


>
>  - it needs a clean target

Done.

The above solution inspired me to sort out creating a build and install area
version of plplot_octave.oct (see recent commit) where again I had to deal
with two distinct files with the same name.  The result is a solution with
no cross-talk between build and installed versions (an issue that is
important to me) and which I believe satisfies the plplot_octave.oct part of
Joao's 'make check' agenda.  I have checked the results with ldd, and, as
expected, the correct library directories are there in each case with no
ambiguity.

I have also checked that the installed version of plplot_octave.oct works
fine.  Joao, can we *please* just leave it at that for now with no more
'make check' related changes until after the release?  I don't want to be
distracted any more from release issues at this critical time.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] COPYING vs COPYING.LIB

[Alan W. I. <ir...@be...>]

On Tue, 24 Dec 2002, Maurice LeBrun wrote:

> Thanks for the explanation.  I agree with your conclusions and will add
> removal of COPYING from the Attic to the list of things the
> cvs-repository-desuckifier script will need to accomplish.

OK.  I have put a copy of COPYING in bindings/octave in anticipation that it
will eventually (post-desuckification....;-)) be nothing but a one-line
place holder in the top-level directory.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] done for now

[Alan W. I. <ir...@be...>]

On Tue, 24 Dec 2002, Maurice LeBrun wrote:

> I've looked at the autoheader [perl] script again and there is no
> short-circuit for the "Preach".

Too bad.

Well, we may be in the middle of a struggle between users who want to keep
old functionality, and the autoconf guys who want to strongly deprecate that
functionality to encourage users to use different functionality which the
autoconf guys feel is superior.  So post-release, it may be worth asking on
the autoconf list (assuming such a mailing list exists) the preferred way to
do what you want.  Meanwhile, we can live with the warning messages.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-devel] more on Makefile.examples

[Maurice L. <mj...@ga...>]

I'd look into fixing these myself but am swamped and need to concentrate on
issues where I am needed most.

 - it'd be a lot better if in the examples dirs, the makefile was named
"Makefile" instead of "Makefile.examples".  Is this straightforward to
put it?

 - it needs a clean target

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] done for now

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > On Mon, 23 Dec 2002, Maurice LeBrun wrote:
 > > BTW it's easy enough to get rid of that irritating message from autoheader by
 > > just editing autoheader and chopping it out.  I think I may just have to make
 > > that my first new FAQ entry in 7 years!
 > 
 > That surgery on autoheader may not be required.
 > 
 > The autoheader script is part of the autoconf package.  From info autoconf
 > and then searching for autoheader options there is a --warn=no-obsolete
 > option.  Can you get that autoheader option to work with your version (2.57)
 > of autoconf? If so, use that option for the autoheader invocation in
 > bootstrap.sh, and it solves the problem.

I've looked at the autoheader [perl] script again and there is no
short-circuit for the "Preach".  There's a test to see if you're using one of
the "deprecated" modes and then $msg is set up and a simple:

    print STDERR $msg;

..no way around it.  Honestly, I think autoconf/etc is a wonderful tool but
sometimes the authors put in stuff that's just plain goofy.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)