plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] [steven.robbins@videotron.ca: Bug#185677: Non-numeric characters in version string upset Tkinter]

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

Steve reported to Rafael who forwarded it here....:

The version string "5.2.0.cvs.20030320" causes Tkinter to choke, viz:

steve@riemann{steve}python
Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
>>> root = Tkinter.Tk()
error reading package index file
/usr/lib/plplot5.2.0.cvs.20030320/pkgIndex.tcl: expected version number but
got
"5.2.0.cvs.20030320"

I have confirmed the problem.  If you follow the cookbook in
examples/tk/README.tkdemos the following error shows up with my March 17th
version number.

wish
% lappend auto_path /usr/local/plplot_at/lib/plplot5.2.0.cvs.20030317
/usr/lib/tcl8.3 /usr/lib /usr/lib/tk8.3
/usr/local/plplot_at/lib/plplot5.2.0.cvs.20030317
% package require Pltk
error reading package index file
/usr/local/plplot_at/lib/plplot5.2.0.cvs.20030317/pkgIndex.tcl: expected
version number but got "5.2.0.cvs.20030317"
can't find package Pltk

That error message is essentially the same that Steve found.  The problem
here is that we are assuming that the package version and plplot tcl script
version should be identical.  However, man package says the version used for
the tcl package command must be numerical (e.g., 5.2.0) with no alphabetic
characters allowed in the version. A change in the major number indicates an
incompatibility in the associated tcl scripts, but the rest of the numbers
should just be increasing with time with no special signficance attached to
them.  This is one more version number we must keep track of for PLplot with
different requirements to the package version (where we do, in general, want
to be able to include alphabetic version information in the string).

For now, I have have solved the problem by defining a new symbol
PLPLOT_TCL_VERSION=5 in configure.ac which is used to configure the
various pkgIndex.tcl files we have (and which are concatanated to form
the installed $prefix/lib/plplot5.2.0.cvs.20030317/pkgIndex.tcl.

I have tentatively assigned this version to be the same as the major version
number of our package (5).  This works on my Debian woody machine where I
have a local prefix other than /usr. Steve, could you quickly try simply
editing /usr/lib/plplot5.2.0.cvs.20030320/pkgIndex.tcl and change *only* the
version numbers that occur on the lines starting with package ifneeded ....
(The other version numbers must remain identical to what they are now.)
Subject to Steve's verification, I believe this fix should stop plplot
gratuitously breaking Tkinter for every Debian unstable user (which should
subtantially improve our Debian public relations....;-))

**BTW, I am no expert on assigning TCL script version numbers (and don't
want to be).** Thus, the tcl experts here should thrash this out and decide
on what is best for PLPLOT_TCL_VERSION each time we make a new release of
plplot based on the script changes that have been made since the previous
release.  For example, Maurice, if you want to change PLPLOT_TCL_VERSION to
5.2.0 rather than 5 (presuming no script changes since 5.2.0), that is fine
with me.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

[Plplot-devel] [steven.robbins@videotron.ca: Bug#185677: Non-numeric characters in version string upset Tkinter]

[Rafael L. <lab...@ps...>]

Hi Steve,

Thanks for your bug report.  I am forwarding it to the PLplot development
mailing list.  I am totally ignorant in Python and Tk, so I am afraid I
cannot help you. Hopefully someone in this forum will be able to do it.

As a matter of fact, I cannot replicate the reported problem with Python 2.1
in Debian testing (sarge).  I will eventually check the behavior in Debian
unstable (sid) with Python 2.2.

At any rate, the presence of ".cvs." in the PLplot version string is only a
transient situation and this problem will vanish when version 5.2.1 will be
released.  I think though that it is important to investigate it, since this
can hide a more serious bug.

-- 
Rafael

[Plplot-devel] Debian pkgs + RC tarball

[Rafael L. <lab...@ps...>]

[ Cross posting to plplot-general and plplot-devel.  Sorry for the
  duplicates. ]

New Debian packages for PLplot have been uploaded to the Debian unstable
distribution (a.k.a sid).  To access them, users have just to point APT to
the appropriate Debian mirror.

For those out there using the testing distribution (a.k.a sarge), the
packages are available at the PLplot website (plplot.sf.net).  Christian
Steigies is providing backported packages for Debian stable (v3.0, a.k.a.
woody).

There is also a new release-candidate tarball available.  For more
information, see:

    http://plplot.sf.net/resources

  
-- 
Rafael

Re: [Plplot-devel] Documentation configure speed problem resolved.

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-03-15 17:11]:

> I think yes, but it may not be worth going to this extra trouble if you have
> a good version of openjade to start with. In my case, the default openjade
> for woody actually turned out to be a development version (1.4devel1-8) that
> lead to 5-minute catalog searches.  (Rafael confirmed these long times when
> he experimentally installed that version as well.  BTW, Rafael, have you
> made a bug report about that?)

Somebody has already done it exactly one year ago:

    http://bugs.debian.org/138924 

-- 
Rafael

[Plplot-devel] Dependency issues straightened out for docbook tree

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

I finally got a chance today to fix up a lot of dependency issues in the
docbook/Makefile.am and docbook/src/Makefile.am.  I replaced all file.in
prerequisites by file prerequisites where appropriate (as Rafael suggested
it was possible to do now). Rafael, could you give it a try and see whether
your recent autoconf fix cuts down on unnecessary building for these
tightened rules?

I also have added many other prerequisites that were just plain missing
before. (One of those nailed me early this morning which highly motivated
today's work!)

I have also changed to a clearer style where you use ordinary automake
commands rather than a recursive make to build the targets that are
required.

The only make commands left in these Makefile.am files are the necessary
recursive makes used to iterate the jadetex and pdfjadetex commands and

$(MAKE) dist && touch dist-stamp

which I guess is necessary for the overall make dist to work properly. (Or
is there a make dist hook of some kind to do the same thing?)

I also rebuilt the documentation and uploaded it to the web site using

make www-install

Now that the dependencies are working properly, it is a simple matter to do
this after cvs updating any one else's documentation fix (or if I make a
documentation change myself).  It also sounds like Joao is very close to
being able to build and www-install the documentation as well.

I finally may get a chance to look at building the documentation on RH 7.3 and
8.0 tomorrow, but no promises.

Alan

__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Documentation configure speed problem resolved.

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

On Sat, 15 Mar 2003, Joao Cardoso wrote:

> On Tuesday 11 March 2003 17:14, Alan W. Irwin wrote:

> > Rafael and I finally found the cause of this problem.  Upgrading the sgml
> > tools installed on my machine increased my docbook configuration speed by
> > literally a factor of 30!
>
> Is this the only issue? From what I understand, if one supplies to configure a
> catalog focused on the needed DTDs, the search will be faster; if by contrary
> the catalog has many entries and the required ones are at the end, the search
> will be slower. I'm right?

I think yes, but it may not be worth going to this extra trouble if you have
a good version of openjade to start with. In my case, the default openjade
for woody actually turned out to be a development version (1.4devel1-8) that
lead to 5-minute catalog searches.  (Rafael confirmed these long times when
he experimentally installed that version as well.  BTW, Rafael, have you
made a bug report about that?) When I installed an older version
(openjade1.3) that search is reduced to a few seconds.  I think you are
right and you could get even smaller search times than that by making your
own catalog, but it is probably not worth it if you already have a version
of openjade that can do fast system catalog searches.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Docbook configuration

[Rafael L. <lab...@ps...>]

* Joao Cardoso <jc...@fe...> [2003-03-15 23:01]:

> Nope. Why can you build it and not me? What I'm missing?

The XML::Parser module in your system (or the underlying expat library) is
apparently pickier than mine as regards non defined entities.  I tried to
circumvent this problem by brute-force inclusion of definitions in
plplotdoc.xml-info. However, from the error message that you posted, I
discovered that there was one left, which is fixed now.  There are possibly
others, and I ask you to be patient and try again with the newest CVS
sources.  We will have to interact this way, since I do not have access to a
system similar to yours.

To avoid cluttering the mailing list, please send the next bug report
privately to me.

-- 
Rafael

Re: [Plplot-devel] Documentation configure speed problem resolved.

[Joao C. <jc...@fe...>]

On Tuesday 11 March 2003 17:14, Alan W. Irwin wrote:
> On Sun, 9 Mar 2003, Alan W. Irwin wrote:
> > Currently, the reason why most developers would want to avoid
> > --enable-docbook (even if it is straightforward to get the prerequisite
> > packages installed) is it currently takes something like 6 minutes on my
> > computer just to configure --enable-docbook.  Rafael, do you know why it
> > is so slow?  That's a ridiculous amount of computer time just to
> > configure something.  There has got to be a better way.
>
> Rafael and I finally found the cause of this problem.  Upgrading the sgml
> tools installed on my machine increased my docbook configuration speed by
> literally a factor of 30!

Is this the only issue? From what I understand, if one supplies to configure a 
catalog focused on the needed DTDs, the search will be faster; if by contrary 
the catalog has many entries and the required ones are at the end, the search 
will be slower. I'm right?

Joao

> So once the rest of you are starting to try
> documentation builds, be careful of this tool version issue.  I will
> eventually document in README.developers the minimum recommended versions
> of everything.
>
> Alan

Re: [Plplot-devel] libqhull

[Joao C. <jc...@fe...>]

On Saturday 15 March 2003 10:02, Rafael Laboissiere wrote:
> * Joao Cardoso <jc...@fe...> [2003-03-15 01:16]:
> > On Saturday 15 March 2003 00:28, Rafael Laboissiere wrote:
> > > I searched a little bit further and found the excerpt below in the
> > > configure.in file of the GSL project
> > > (http://www.gnu.org/software/gsl/). This autoconf code is doing pretty
> > > much the same thing as your code in sysloc.in, besides an compilation
> > > exercise to check if the flags are really accepted in the alpha
> > > architecture.
> >
> > hmm, I would like a better test, not just that the flag is accepted.
>
> Do you wiush that the compilation exercise be introduced in our
> configure.ac?  I can do it (but not test it fully, since I have no access
> to alpha machines).

It would be nice.

The following program is a minimal test that does not guarantees that nn/csa 
and x21c.c  will run OK. It tests a necessary but not sufficient condition.

The other longer program I posted tests for sufficiency.

#include <math.h>

main()
{
        double x;
        x = sqrt(-1.);
        if (x == x)
                return 1;
        return 0;
}


On a alpha/OSF:

bash-2.01$ cc -ieee po.c -o po -lm && if ./po; then echo yes; else echo no; fi
yes
bash-2.01$ cc po.c -o po -lm && if ./po; then echo yes; else echo no; fi
no
bash-2.01$ gcc po.c -o po -lm && if ./po; then echo yes; else echo no; fi
no
bash-2.01$ gcc -mieee po.c -o po -lm && if ./po; then echo yes; else echo no; 
fi 
yes

On linux:

jcard@jcard:~> gcc  po.c -o po -lm && if ./po; then echo yes; else echo no; fi
yes
jcard@jcard:~> gcc -mieee-fp po.c -o po -lm && if ./po; then echo yes; else 
echo no; fi
yes

On linux it does not seems to make a difference, but -mieee-fp is recomended.

Joao

Re: [Plplot-devel] PLplot Docbook configuration

[Joao C. <jc...@fe...>]

On Saturday 15 March 2003 16:15, Rafael Laboissiere wrote:
> * Jo=E3o Cardoso <jc...@fe...> [2003-03-14 17:46]:
> > On Friday 14 March 2003 17:03, Rafael Laboissiere wrote:
> > | * Jo=E3o Cardoso <jc...@fe...> [2003-03-14 16:33]:
> >
> > ...
> >
> > | Nothing.  I will change the DTD requierement to 4.2, as this is
> > | anyway the most appropriate thing to do.
> >
> > Now the detection phase runs OK, and some docs are built, but I still
> > get an error:
> >
> > [...]
>
> Cold you please test with the newest cvs sources?  I just committed some
> changes that may (hopefully) fix this problem.

Nope. Why can you build it and not me? What I'm missing?

=2E..
ls: *.info*: No such file or directory
make[4]: Entering directory `/home/jcard/plplot/doc/docbook/src'
if perl -I/home/jcard/plplot/doc/docbook/perl=20
/home/jcard/plplot/doc/docbook/perl/docbook2texixml plplotdoc.xml-info >=20
plplotdoc.txml-tmp ; then \
  mv plplotdoc.txml-tmp plplotdoc.txml ; \
else \
  false ; \
fi

undefined entity at line 77, column 67, byte 4157
error in processing external entity reference at line 332, column 6, byte=20
16414 at /usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi/XML/Parser.=
pm=20
line 185
make[4]: *** [plplotdoc.txml] Error 1

[Plplot-devel] New constraints imposed on plplot-test.sh

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

Some time ago, Rafael discovered that plplot-test.sh could be executed from
any directory for the installed version of the octave and java front ends
potentially generating tons of *.ps, etc., files in a directory where you
might not like them.  (This is not possible for the other front ends since
certain subdirectories are required.)

I have decided that the best way to deal with this situation is to impose
the constraints that this script can only be run from a directory named
"examples" with subdirectory "c" consistent with its original design.

If anyone here finds these constraints too restrictive I will reconsider
imposing them.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Docbook configuration

[Rafael L. <lab...@ps...>]

* João Cardoso <jc...@fe...> [2003-03-14 17:46]:

> On Friday 14 March 2003 17:03, Rafael Laboissiere wrote:
> | * João Cardoso <jc...@fe...> [2003-03-14 16:33]:
> ...
> | Nothing.  I will change the DTD requierement to 4.2, as this is
> | anyway the most appropriate thing to do.
> 
> Now the detection phase runs OK, and some docs are built, but I still 
> get an error:
> 
> [...]

Cold you please test with the newest cvs sources?  I just committed some
changes that may (hopefully) fix this problem.

-- 
Rafael

Re: [Plplot-devel] Additions to api.xml

[Rafael L. <lab...@ps...>]

* Joao Cardoso <jc...@fe...> [2003-03-15 01:07]:

> On Friday 14 March 2003 22:12, Maurice LeBrun wrote:
> >  - the entry for plsurf3d is missing
> 
> The entry called plotsh3d should be named plsurf3d. Fixed now.

I just made the necessary changes to advanced.xml and plplotdoc.xml.in,
also.

-- 
Rafael

Re: [Plplot-devel] libqhull

[Rafael L. <lab...@ps...>]

* Joao Cardoso <jc...@fe...> [2003-03-15 01:16]:

> On Saturday 15 March 2003 00:28, Rafael Laboissiere wrote:
> > I searched a little bit further and found the excerpt below in the
> > configure.in file of the GSL project (http://www.gnu.org/software/gsl/).
> > This autoconf code is doing pretty much the same thing as your code in
> > sysloc.in, besides an compilation exercise to check if the flags are really
> > accepted in the alpha architecture.
> 
> hmm, I would like a better test, not just that the flag is accepted.

Do you wiush that the compilation exercise be introduced in our
configure.ac?  I can do it (but not test it fully, since I have no access to
alpha machines).

-- 
Rafael

Re: [Plplot-devel] Re: [Plplot-general] libqhull

[Joao C. <jc...@fe...>]

On Friday 14 March 2003 21:18, Alan W. Irwin wrote:
> On Fri, 14 Mar 2003, Rafael Laboissiere wrote:
> > * Alan W. Irwin <ir...@be...> [2003-03-14 09:26]:
> > > On Fri, 14 Mar 2003, Rafael Laboissiere wrote:
> > > > Long answer: This is a bad side-effect of using plplot_libtool,
> > > > instead of a full-fledged solution with the right libraries put in
> > > > the Makefile.
> > >
> > > NO.  You keep forgetting that libtool is a configured script that is
> > > adjusted exactly (and only) for the build system.  See below.
> >
> > Yes, this ideal situation only happens when the user build himself both
> > libqhull and libplplot in the same system and never removed the
> > libqhull.la file.
>
> No.  Joao's, your, and my systems are the counter-examples here.  None of
> us (I assume) built libqhull.

I dont know what you are talking about, but I had to build qhull from source.
Of course this is no argument to none of you, Alan and Rafael, because qhull 
"configure" was written by Rafael :)

Joao

Re: [Plplot-devel] libqhull

[Joao C. <jc...@fe...>]

On Saturday 15 March 2003 00:28, Rafael Laboissiere wrote:
> * Rafael Laboissiere <lab...@ps...> [2003-03-14 22:48]:
> > * Joao Cardoso <jc...@fe...> [2003-03-14 19:58]:
> > > Please check in sysloc.in for mieee-fp and correct it so it becomes
> > > "The Right Way To Do It" (TM - Rafael :)
> >
> > I am sorry, but in this case I do not now the Right Way (TM).  Even in
> > the GNU Autoconf Macro Archive (http://www.gnu.org/software/ac-archive/)
> > there seems to be nothing regarding the cross-platform setting of the
> > ieee compilation flag.
>
> I searched a little bit further and found the excerpt below in the
> configure.in file of the GSL project (http://www.gnu.org/software/gsl/).
> This autoconf code is doing pretty much the same thing as your code in
> sysloc.in, besides an compilation exercise to check if the flags are really
> accepted in the alpha architecture.

hmm, I would like a better test, not just that the flag is accepted.

>
> The fact that the code below only acts on CFLAGS for the alpha architecture
> is a good indication that your code in sysloc.in should work for all the
> other architectures, since they do not seem to need special treatment
> regarding the ieee flag.

Well, I will trust them. Also, Octave deals with that issue the same way. If 
GSL copied the settings from Octave (I think Octave is older), and we now 
trust them both, who shall we blame in case we are wrong? we of course ;-)

Thanks,
Joao

Re: [Plplot-devel] Additions to api.xml

[Joao C. <jc...@fe...>]

On Friday 14 March 2003 22:12, Maurice LeBrun wrote:
> Jo=E3o Cardoso writes:
>  > Hi,
>  >
>  > I have updated/changed/added some API entries in api.xml.
>  > PLEASE review the changes, which are in:
>  >
>  > plenv, plenv0, plclear, plgriddata, plmesh, plmeshc, plot3d, plot3dc,
>  > plsurf3d. plotsh3d was deleted.
>
> I just finished looking at these in the installed documentation --
> http://plplot.sourceforge.net/resources/docbook-manual/plplot-html-5.2.0/
> and noticed:
>  - the entry for plmeshc calls it plmesh
>  - the entry for plsurf3d is missing

The entry called plotsh3d should be named plsurf3d. Fixed now.

Thanks,
Joao

Re: [Plplot-devel] libqhull

[Rafael L. <lab...@ps...>]

* Rafael Laboissiere <lab...@ps...> [2003-03-14 22:48]:

> * Joao Cardoso <jc...@fe...> [2003-03-14 19:58]:
> 
> > Please check in sysloc.in for mieee-fp and correct it so it becomes "The
> > Right Way To Do It" (TM - Rafael :)
> 
> I am sorry, but in this case I do not now the Right Way (TM).  Even in the
> GNU Autoconf Macro Archive (http://www.gnu.org/software/ac-archive/) there
> seems to be nothing regarding the cross-platform setting of the ieee
> compilation flag.

I searched a little bit further and found the excerpt below in the
configure.in file of the GSL project (http://www.gnu.org/software/gsl/).
This autoconf code is doing pretty much the same thing as your code in
sysloc.in, besides an compilation exercise to check if the flags are really
accepted in the alpha architecture.

The fact that the code below only acts on CFLAGS for the alpha architecture
is a good indication that your code in sysloc.in should work for all the
other architectures, since they do not seem to need special treatment 
regarding the ieee flag.

-- 
Rafael



AC_MSG_CHECKING([for IEEE-conformance compiler flags])
save_cflags="$CFLAGS"
case "$host" in
    alpha*-*-*)
        if test X"$GCC"= Xyes ; then
                ieee_alpha_options='-mieee'
                CFLAGS="$ieee_alpha_options $CFLAGS"
        else
                # This assumes Compaq's C compiler, which is probably
                # a pretty bad assumption.  Improvements welcome.
                ieee_alpha_options='-ieee'
                CFLAGS="$ieee_alpha_options $CFLAGS"
        fi
        #
        # now see if the option we think should be accepted actually is
        #
        AC_TRY_COMPILE( ,[ int foo; ],[
                AC_MSG_RESULT([$ieee_alpha_options])
                dnl
                dnl after the check is over, CFLAGS will become save_cflags,
                dnl which has just acquired the additional flag.
                dnl
                save_cflags="$CFLAGS"
                ],[
                AC_MSG_RESULT([unknown!])
                AC_MSG_WARN(
                [I don't know how to enable full IEEE mode with your compiler]
                )
                ]
        )       dnl here ends our AC_TRY_COMPILE
        ;;
    *)
        AC_MSG_RESULT([none])
        ;;
esac
# Now restore our (possibly augmented) CFLAGS.
CFLAGS="$save_cflags"
 

Re: [Plplot-devel] Additions to api.xml

[Rafael L. <lab...@ps...>]

* Maurice LeBrun <mj...@ga...> [2003-03-14 16:12]:

> I just finished looking at these in the installed documentation --
> http://plplot.sourceforge.net/resources/docbook-manual/plplot-html-5.2.0/
> and noticed:
>  - the entry for plmeshc calls it plmesh
>  - the entry for plsurf3d is missing

The first is already fixed in CVS.  The second is not that easy to fix...
 
-- 
Rafael

Re: [Plplot-devel] Additions to api.xml

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

Jo=E3o Cardoso writes:
 >=20
 > Hi,
 >=20
 > I have updated/changed/added some API entries in api.xml.
 > PLEASE review the changes, which are in:
 >=20
 > plenv, plenv0, plclear, plgriddata, plmesh, plmeshc, plot3d, plot3dc=
,=20
 > plsurf3d. plotsh3d was deleted.

I just finished looking at these in the installed documentation --
http://plplot.sourceforge.net/resources/docbook-manual/plplot-html-5.2.=
0/
and noticed:
 - the entry for plmeshc calls it plmesh
 - the entry for plsurf3d is missing

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

Re: [Plplot-devel] libqhull

[Rafael L. <lab...@ps...>]

* Joao Cardoso <jc...@fe...> [2003-03-14 19:58]:

> Please check in sysloc.in for mieee-fp and correct it so it becomes "The
> Right Way To Do It" (TM - Rafael :)

I am sorry, but in this case I do not now the Right Way (TM).  Even in the
GNU Autoconf Macro Archive (http://www.gnu.org/software/ac-archive/) there
seems to be nothing regarding the cross-platform setting of the ieee
compilation flag.

In any case, the code that you inserted in sysloc.in with the settings of
CFLAGS looks correct to me.

Your idea of sending a RFC to plplot-general is a good one.  Go ahead.

-- 
Rafael

Re: [Plplot-devel] Re: [Plplot-general] libqhull

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

On Fri, 14 Mar 2003, Rafael Laboissiere wrote:

> * Alan W. Irwin <ir...@be...> [2003-03-14 09:26]:
>
> > On Fri, 14 Mar 2003, Rafael Laboissiere wrote:
> >
> > > Long answer: This is a bad side-effect of using plplot_libtool, instead of a
> > > full-fledged solution with the right libraries put in the Makefile.
> >
> > NO.  You keep forgetting that libtool is a configured script that is
> > adjusted exactly (and only) for the build system.  See below.
>
> Yes, this ideal situation only happens when the user build himself both
> libqhull and libplplot in the same system and never removed the libqhull.la
> file.

No.  Joao's, your, and my systems are the counter-examples here.  None of us
(I assume) built libqhull.  Instead, it was supplied as a binary with and
without libqhull.la on our various systems, yet for that variety of
situations plplot_libtool is working fine. Essentially the user should not
go wrong if they stick with the system where they built plplot and use the
plplot_libtool script configured for that system.

It is a different story if a binary package of plplot is provided, but that
is a controlled environment where you know exactly what was on the build
machine, and you can force the user to also install the same.  In that case
if you get the libplplot-dev package dependencies correct, then again the
user cannot go wrong using plplot_libtool.


> A mismatch happened with my Debian packages, as reported by
> Christophe.  So, the bad side effect may and _does_ happen in some cases.  I
> already decided to change the libplplot-dev package dependencies, so there
> will be no problem.
>

No.  Actually, the problem was that Christophe had not installed the dev
packages, and the problem went away when he did so.  So that definitely does
not prove your case that something must be wrong with plplot_libtool.

To sum this up, there are no demonstrated problems with plplot_libtool
either when the user is building plplot or in the binary plplot package case
when the dev package dependencies are correct. Thus, "If it ain't broke
don't fix it."

Will you quit complaining about plplot_libtool if I change its name to
plplot-libtool?   ;-)  (To explain the joke to the rest of you, Rafael
has told me in the past that he hates underscores and loves hyphens.)

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] libqhull

[Joao C. <jc...@fe...>]

On Friday 14 March 2003 18:56, Rafael Laboissiere wrote:
> * Jo=E3o Cardoso <jc...@fe...> [2003-03-14 17:26]:
> > But I still have doubts with nn/csa, because of NaN issues.
> > I'm thinking in posting a RFC in the general list, asking for people
> > with non linux system to test a test program, that I attach.
> >
> > Under OSF/alpha, it must be compiled as
> >
> >    gcc -mieee nantest.c -o nantest -lm
> >
> > or, using the native compiler,
> >
> >   cc -ieee nantest.c -o nantest -lm
> >
> > Under linux, a plain gcc ... -lm will do the work, although adding the
> > -mieee-fp flag is the recomended approach.
>
> Do you wish a new configure check to add the necessary flags for OSF/Alpha
> (or other systems)?

They are already there... but when new systems are know, it might be=20
necessary.

Please check in sysloc.in for mieee-fp and correct it so it becomes "The Ri=
ght=20
Way To Do It" (TM - Rafael :)

Joao

Re: [Plplot-devel] libqhull

[Rafael L. <lab...@ps...>]

* João Cardoso <jc...@fe...> [2003-03-14 17:26]:

> But I still have doubts with nn/csa, because of NaN issues.
> I'm thinking in posting a RFC in the general list, asking for people 
> with non linux system to test a test program, that I attach.
> 
> Under OSF/alpha, it must be compiled as
> 
>    gcc -mieee nantest.c -o nantest -lm
> 
> or, using the native compiler,
> 
>   cc -ieee nantest.c -o nantest -lm
> 
> Under linux, a plain gcc ... -lm will do the work, although adding the 
> -mieee-fp flag is the recomended approach.

Do you wish a new configure check to add the necessary flags for OSF/Alpha
(or other systems)?

-- 
Rafael

Re: [Plplot-devel] Re: [Plplot-general] libqhull

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-03-14 09:26]:

> On Fri, 14 Mar 2003, Rafael Laboissiere wrote:
> 
> > Long answer: This is a bad side-effect of using plplot_libtool, instead of a
> > full-fledged solution with the right libraries put in the Makefile.
> 
> NO.  You keep forgetting that libtool is a configured script that is
> adjusted exactly (and only) for the build system.  See below.

Yes, this ideal situation only happens when the user build himself both
libqhull and libplplot in the same system and never removed the libqhull.la
file.  A mismatch happened with my Debian packages, as reported by
Christophe.  So, the bad side effect may and _does_ happen in some cases.  I
already decided to change the libplplot-dev package dependencies, so there
will be no problem.  

But there is another reason we need an alternative to using the
plplot_libtool script.  Imagine that in the future somebody writes an
application that should link againt the PLplot library.  How will this
person configure her software in order to get the right libraries and cflags
options?  For now, this is easy to do using pkg-config:

    $ pkg-config plplot --cflags 
    -DPL_DOUBLE  
    $ pkg-config plplot --libs
    -lplplotd -lfreetype  

Notice that the results are still probably incorrect, but I have plans to
fix that.

> > The
> > problem comes from here:
> >
> >     $ grep libqhull /usr/lib/libplplotd.la
> >     dependency_libs='/usr/lib/libfreetype.la -lz /usr/lib/libcsa.la
> >     /usr/lib/libnn.la /usr/lib/libqhull.la -lm -ldl'
> >
> > I may try to find a way to force the use of "-lqhull" instead of
> > "/usr/lib/libqhull.la" in that file, because libqhull is not provided by the
> > PLplot pakcage.  Same thing for -lfreetype.  I dunno if this is possible
> > with libtool, but I will look at it.
> 
> Do NOT do this.  I am surprised I have to go into libtool advocacy mode here
> with you on this.

Are you trying to evangelize the priest? :-) Joao just wrote the following,
referring to me:

* Joao Cardoso <jc...@fe...> [2003-03-14 17:26]:
> [...] You are the one that religiously :) believe in libtool, not me :)

* Alan W. Irwin <ir...@be...> [2003-03-14 09:26]:

> Our joint experience is it usually does exactly the right thing, and that
> proves to be the case this time as well.  It simply is configured to do the
> right thing on the build system.  In my case (Debian woody) I have an older
> qhull which was not built with libtool so there is no libqhull.la. But
> libtool is configured appropriately for that situation on my system.
> 
> grep qhull /usr/local/plplot_at/lib/libplplotd.la
> dependency_libs=' /usr/lib/libfreetype.la /usr/local/plplot_at/lib/libcsa.la
> /usr/local/plplot_at/lib/libnn.la -lqhull -lm -ldl'
> 
> Note in this case -lqhull is used.

Oh, you just replicated the analysis that I already send to the mailing list
in replying to Joao...  Well, redundancy is always good to have things
really assimilated by the others.

> So the linking will be fine for all cases.  Remember, libtool (and
> therefore the local copy of that script, plplot-libtool) is configured just
> for the build system so you cannot generalize the result on one system to
> what will happen on others.

I never did this generalization...

> > Otherwise, I will probably add a dependency on libqhull-dev and
> > libfreetype6-dev to libplplot-dev.
> 
> This is the correct approach.  If the user wants to build the examples he
> will obviously need libplplot-dev which will bring in the rest of the
> required dev packages.

This is what I already did in my local cvs tree.  Will be in the upcoming
Debian release.

-- 
Rafael