mkpkgadd

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

mkpkgadd

Paul Kienzle
Hi,

I've started adding PKGADD stuff to octave-forge.  

(1) The simplist thing to do is use mkpkgadd directly from octave.
 Obviously I
will need to put in my own copy for this release, but shouldn't mkpkgadd be
added to /usr/local/bin, or maybe
/usr/local/libexec/octave-2.1.xx/exec/arch-xxx
assuming octave-config can report the location of the exec path to the
makefile?

(2) oct-file functions may also need PKGADD stuff --- either for my as yet
unfinished type dispatch stuff or for marking them as text commands.  But
mkpkgadd operates on the installed directory, not on the source
directory, so
any PKGADD stuff would be lost.  Should the PKGADD file act more like
a database which can replace the directives associated with a file when
you install a new file in the directory? Or should I create a file such as
<mypackage>.add which mkpkgadd automatically concatenates
when it builds the PKGADD file?  Presumably <mypackage>.add
would be built automatically by somthing like mkpkgadd which scans
the C++, C and Fortran files for ## PKGADD directives.  

We will need something similar to process embedded test cases.  

And the same for help strings.  That way we wouldn't have to embed them
in string constants, but instead say ## HELP followed by the help string.  
We could almost do this now using document, except that document is
associated with actual symbols in the symbol table, not ones that we
promise will be there.

Hmmm...., how could we get spfind, the find function which works for
sparse [which will eventually be dispatched on find when the first argument
is a sparse matrix], to add a blurb to the help description for find
saying that it
also works on sparse matrices?  document_add(x,text) maybe?

Paul Kienzle
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: mkpkgadd

Andy Adler
On Sun, 5 Jan 2003, Paul Kienzle wrote:
> I've started adding PKGADD stuff to octave-forge.

I'm sorry, I haven't heard about PKGADD before.
It seems to be a fairly important thing to understand.

Could anyone refer me to a place where I could learn
about what PKGADD is and how to deal with it?

Thanks

Andy


Reply | Threaded
Open this post in threaded view
|

Re: mkpkgadd

John W. Eaton-6
On  5-Jan-2003, Andy Adler <[hidden email]> wrote:

| On Sun, 5 Jan 2003, Paul Kienzle wrote:
| > I've started adding PKGADD stuff to octave-forge.
|
| I'm sorry, I haven't heard about PKGADD before.
| It seems to be a fairly important thing to understand.
|
| Could anyone refer me to a place where I could learn
| about what PKGADD is and how to deal with it?

This feature is new with the most recent snapshots and current CVS
sources.

Now when Octave adds a directory to the load path, it looks for a file
called PKG_ADD in that directory, and if it exists, reads it and
executes any commands found in it.  Any valid Octave code can go in
these files, so it is like a per-directory octaverc file.

The motivation for adding this feature was to have a place to put
the new "mark_as_command" declaration statements that allow us to mark
M-file functions as commands so they can be called as (for example)

  grid on

instead of

  grid ("on")

Currently, the only things in any PKG_ADD files that are installed
with Octave are a few "mark_as_command" statements, but we may use
these files for more in the future.

There is a script in the CVS archive (I accidentally omitted it from
the latest snapshot files, but it will be in 2.1.44) called mkpkgadd
that is used when installing M-files.  It looks for lines like

  ## PKG_ADD: ... code ...

in M-files and copies the "... code ..." part to the PKG_ADD file that
goes in the directory where the M-files are installed.  You'll have to
look at the Makefiles in the scripts directory to see how it is used.

Also, when a directory removed from the load path, Octave looks for a
file called PKG_DEL in the directory that is being removed, and runs
commands found there.  So far we are not using this feature, but it
could be useful if you want to clean up after a package that has been
removed from the load path (for example, to remove global variables,
or close and clean up temporary files, etc.).

jwe