Re: Requirements for releasing the STK toolbox as an Octave forge package ?

[Julien Bect]

On 24/02/2014 19:50, Carnë Draug wrote:
> On 24 February 2014 16:57, Julien Bect <address@hidden> wrote:
> > Which undocumented feature am I relying on, exactly ?
> You are assuming that the current working directory during pre_install
> is the directory of your uncompressed package, and that pkg will
> maintain whatever structure you have inside the inst/ for
> installation. I believe these should be good expectations though, I'm
> just reminding you that this is undocumented.

Concerning the first assumption, I have replaced: pkg_dir = pwd;

with: pkg_dir = fileparts (mfilename ('fullpath'));

Is it still too much to assume, that pre_install.m is still located at 
the root of the package directory with the function pre_install () is 
called ?


> This also causes other trouble. For example, I'll guess this is what
> causing you to add isoctave and ismatlab to the path, that the common
> diretory is actually what you would like to be the private functions
> shared among the whole package. Other packages aim at Matlab
> compatibility and may have their own version of this functions. If
> each packages adds their own version to the path.... You also have
> commonsize() and graphicstoolkit(). Which one will your package use
> when multiple packages are loaded with this functions? If you had
> everything on the same directory, you can place them all under a
> private directory.

You're actually pointing at the only four functions that are not 
prefixed by stk_...

Anyway, you're right, I will make sure that no function without an 
stk_prefix is added to the path.


> > Concerning the other three warnings : I know, I can see them too, but as I
> > told you the warning is inaccurate since I'm not acutally adding these to
> > the path. Anyway, I will simply remove them if they are not needed, which
> > should make the warnings disappear. Is it OK if I delete them from inst in
> > the pre_install script ?
> Should be fine. But isn't it easier to simply not add them to the
> package? Why risk it have it done multiple time under many different
> conditions during installation, when it can be done only once during
> package release in a controlled environment?

The point is to ensure that the package works in older releases of 
Octave. For instance, linsolve is not available in 3.6.4.


> > > Also, the way you move the mex files into the same directory as m
> > > files is not recommended. Downstream packages are unlikely to be happy
> > > about it, since architecture dependent files are supposed to be kept
> > > separated.
> > I didn't know that... How can I separate architecture dependent-files from
> > architecture independent files when i have MEX-files inside private
> > directories ? (The same question would be relevant for MEX-files in class
> > directories, but I don't have any of them.)
> You can't. The convention is to name them __foo__. This is also what
> Octave core does.

Ok, I get it. I will rename them to __stk_***__ and leave them in /src 
(from where, if I understand correctly, they will be moved to the 
appropriate directory for architecture-dependent files).

Thank you for your advices.