Suggestion: startup.d subdirectory for use by octaverc

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

Suggestion: startup.d subdirectory for use by octaverc

James R. Phillips-2
It occurs to me that octave could benefit from startup logic similar to (but
simpler than) that used by linux init scripts.

Right now the octaverc startup scripts are empty, ootb.  If they were instead
setup to look for and execute any files in subdirectory startup.d, say, then
3'rd party octave packages could easily install/remove their own startup
scripts without requiring hand-editing by the user/administrator.

Worth doing?

Jim Phillips

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion: startup.d subdirectory for use by octaverc

Paul Kienzle
We already have this---through a PKG_ADD file in your package directory
and all octave commands therein will be run.  IIRC, PKG_DEL is run when
the directory is removed from the path.

- Paul

On Jul 3, 2005, at 2:57 PM, James R. Phillips wrote:

> It occurs to me that octave could benefit from startup logic similar
> to (but
> simpler than) that used by linux init scripts.
>
> Right now the octaverc startup scripts are empty, ootb.  If they were
> instead
> setup to look for and execute any files in subdirectory startup.d,
> say, then
> 3'rd party octave packages could easily install/remove their own
> startup
> scripts without requiring hand-editing by the user/administrator.
>
> Worth doing?
>
> Jim Phillips
>

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion: startup.d subdirectory for use by octaverc

James R. Phillips-2
In reply to this post by James R. Phillips-2
--- Paul Kienzle  wrote:

> We already have this---through a PKG_ADD file in your package directory
> and all octave commands therein will be run.  IIRC, PKG_DEL is run when
> the directory is removed from the path.

Hmm.  No documentation that I can find within octave on this.  Did find this
comment in list archives:

http://www.octave.org/octave-lists/archive/octave-maintainers.2002/msg00175.html

===========
There is also some new code for declaring commands at startup time.
Now when a directory is added to the LOAADPATH, Octave looks for a
file called PKG_ADD in the directory, and if it is present, reads and
executes commands from it.
===========

OK.  But actually, what I had in mind was exactly the issue of adding a
directory to the LOADPATH, which is typically done in octaverc, and must be
done before PKG_ADD is of any assistance.  Scripts to do this could be put in a
startup.d directory with octaverc.  They could then be added or deleted from
the subdirectory as necessary, in concert with package addition or deletion,
and without requiring edits of octaverc.



Reply | Threaded
Open this post in threaded view
|

Re: Suggestion: startup.d subdirectory for use by octaverc

James R. Phillips-2
In reply to this post by James R. Phillips-2

--- Paul Kienzle  wrote:


> Anything in the system path is automatically located in octave.  If it
> is not on the system path, but in some personal path, you can add e.g.,
> LOADPATH=["~/octave//:",LOADPATH] to your .octaverc file and all
> packages within ~/octave and all its subdirectories will be
> automatically loaded.
>

I detect a certain lack of enthusiasm for my idea ;).

Sure, I am aware of this feature.  I'm thinking in terms of system
administration and packaging design, not so much of user-installed packages.
Actually, I'm thinking ahead to producing an octave-forge package for cygwin,
and it seemed this feature might be handy, to eliminate the need for a
post-install script that adds the octave-forge load path by editing octaverc.

The problem-solving principle here is one of generalization - easier to solve
the general problem than the specific one. [Polya]

But no matter.  If the general problem is of little interest, a more specific
solution will do.

BTW, you're an octave-forge developer, I believe?  I have found that the
octave-forge makefile structure doesn't seem to support "out of tree" builds.
This is a commonly used method to keep the source tree clean during the build,
and is recommended by cygwin developers for cygwin packages.  If you have any
ideas on how to make octave-forge build "out of tree", I'd be interested in
them.  Otherwise I guess I'll just work around the issue.

Jim Phillips

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion: startup.d subdirectory for use by octaverc

Paul Kienzle

On Jul 4, 2005, at 1:19 AM, James R. Phillips wrote:

>
> --- Paul Kienzle  wrote:
>
>
>> Anything in the system path is automatically located in octave.  If it
>> is not on the system path, but in some personal path, you can add
>> e.g.,
>> LOADPATH=["~/octave//:",LOADPATH] to your .octaverc file and all
>> packages within ~/octave and all its subdirectories will be
>> automatically loaded.
>>
>
> I detect a certain lack of enthusiasm for my idea ;).
>
> Sure, I am aware of this feature.  I'm thinking in terms of system
> administration and packaging design, not so much of user-installed
> packages.
> Actually, I'm thinking ahead to producing an octave-forge package for
> cygwin,
> and it seemed this feature might be handy, to eliminate the need for a
> post-install script that adds the octave-forge load path by editing
> octaverc.

My point is that you do not need to add the octave-forge load path to
octaverc if you install it in the standard system place.  Furthermore,
if you have a packaging system for octave which installs user-local
packages, you will only need a single entry in the octaverc file
pointing to the root of the user-local directory, and this will
automatically pick up all the user-local packages.  In either case, you
do not need a post-install script to add the new package to the
LOADPATH. The remaining package-specific startup features that you
might put in startup directory can equally go into the PKG_ADD file for
the package.

So as far as I can tell, adding a startup directory doesn't add any
power or convenience.

> BTW, you're an octave-forge developer, I believe?  I have found that
> the
> octave-forge makefile structure doesn't seem to support "out of tree"
> builds.
> This is a commonly used method to keep the source tree clean during
> the build,
> and is recommended by cygwin developers for cygwin packages.  If you
> have any
> ideas on how to make octave-forge build "out of tree", I'd be
> interested in
> them.  Otherwise I guess I'll just work around the issue.

I played with this a little a while back and concluded I didn't have
time to do it properly.

Rather than spending time fixing the current system, I would recommend
extending Søren's packaging system so that it can handle each of the
octave-forge subdirectories independently, including out of tree
builds, and have a small bit of build glue at the top which triggers
the build in each subdirectory.

- Paul