[Plplot-devel] Re: Recent changes regarding octave/matwrap

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

On Sunday 22 February 2004 18:09, Rafael Laboissiere wrote:
|  [Cc: to plplot-devel]
|
|  Joao,
|
|  I just committed some changes regarding the matwrap support.  We can
| always revert them, if you dislike my ideas, but let us discuss here.
|
|  I have thought about the matwrap support in the Octave binding and
| concluded that its situation is similar to that of Swig.  Therefore, I
| think that they should be treated similarly.

Sure

|  Matwrap is only needed by developers who want to change the Octave binding
|  itself.  Regular users should never have need it.  In PLplot, matwrap
|  generates two architecture independent sources: plplot_stub.m and
|  plplot_octave.cc.  My changes to HEAD make these files to be generated by
|  make dist

And also by a regular make, I hope :). If we want to change something in 
plplot_octave.h do we need to reconfigure? Or a normal make will honour 
dependencies and will regenerate plplot_stub.m and plplot_octave.cc?

| and included in the tarball.  Moreover, they will not be deleted
|  by make clean, only by make maintainer-clean.
|
|  Since matwrap is not needed for regular users anymore, the
|  bindings/octave/matwrap directory is not included in the tarball.

OK

|  I did
| not remove the matwrap files from CVS, though.  If you agree with my
| changes, this removal is the next thing to do.

I don't understand this point. If you remove the matwrap directory, how will  
plplot_stub.m and  plplot_octave.cc be generate? Using a installed matwrap?
The built-in matwrap was slighly modified to work in-place, but if a installed 
matwrap works, that's fine.
However, I think that matwrap is not being maintained anymore, can't this be a 
problem in the future, if the distribution site disapears?

|  In sysloc.in, if the check for matwrap fails, the MATWRAP variable is set
| to:
|
|      MATWRAP="-e 'print qq{matwrap not available in the system\n}' ; false
| "
|
|  and no warning message is output.   This means that the message:
|
|      matwrap not available in the system
|
|  will be sent if no matwrap was detected at configure time and if there is
| an attempt to use matwrap in bindings/octave/Makefile.
|
|  The advantages of my changes are:
|
|     * Avoid distribution of third party stuff in the tarball

Agreed

|     * No need to build matwrap-generated files by regular users (faster
|       build)

Fine

|  What do you think?

That's fine, as long as a standard matwrap can be used and if a normal make 
honours dependencies.

I think that at this point you are more concerned with making tarbals, 
releases, etc, and making our users life easier, but please don't forget us, 
the developpers, developping (the modify, make, test cycle) must not be a 
pain  ;-)

Joao