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

[Julien Bect]

On 24/02/2014 17:20, Carnë Draug wrote:
> > Could you please try to step through stk_init.m to understand why it is
> > called several times ?
> I found the problem. the problem is when stk_init calls clear which is
> modified on my side to, among other things, reload packages. Because
> of this, it gets stuck into a loop reloading the stk package.
>
> Reverting my local changes to clear, I could load it correctly. While
> you remove most of the temporary variables, it seems your script
> forgets two of them "STK_SKIP_BUILDMEX" and "mole_dir"

This is now fixed, thank you.

> > > Also, why do you have the functions split into multiple directories?
> > > If you are already creating the package with a script, there's no need
> > > for organization, you might as well place all the m files into a
> > > single directory. This will also make it simpler for you, and will be
> > > less prone to bugs when adding and removing to the search path.
> > As a user, I prefer when I can browse the source tree and understand from
> > its structure how the toolbox/package/module/... is organized. So, yes, I
> > know that I could put everything into a single directory, but I would really
> > prefer to keep the original layout if possible (I see that the LTFAT package
> > has subdirectories, for instance, so it shouldn't be a problem).
> >
> > Plus, the packaging script would be more delicate to write, since not
> > everything must be flattened out (for instance, we have private
> > subdirectories, class subdirectories, and even class subdirectories that
> > contain private subdirectories that contain MEX-files...).
> >
> > Of course, if it turns out that this is the only to make it work, I will do
> > that.
> I know other packages do it and they all have that reason. I still
> always advise against it. Managing path manually is a pain and likely
> to cause unexpected problems. And if Octave ever changes how it
> manages packages internally, it will suddenly break. You are relying
> on things which, albeit stable, are undocumented and not meant to be
> used.

Well, I certainly don't want things to "break suddenly" if I can avoid it...

Which undocumented feature am I relying on, exactly ?

> > > By the way, the package is shadowing the following core functions:
> > > linsolve, qunatile, and corr. Why is it doing this?
> > It's not shadowing anything : the error message that you quote is
> > inaccurate...
> >
> > The functions that you mention are provided for compatibility with older
> > versions of Octave (for instance, 3.2.4 has neither corr nor linsolve) and
> > to avoid a dependency on the Statistics toolbox for Matlab users. They are
> > only added to the path if it is detected at runtime that they are missing
> > (see misc/mole/PKG_ADD.m).
> >
> > I will remove them during the installation if it is detected that they are
> > not needed...
> This is what I get when I install the package
> http://bpaste.net/show/WaA1RPB6zuIYx0wwXbGB

I have never seen the first warning that you get (concerning 
stk_dist_matrixx.mex). Do you know what it means ?

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 ?

> I found the problem why generate_html is not working for you. There is
> no INDEX file. When it is missing, it will create one automatically
> from the directories where it placed the functions. Since the
> functions are not where they are supposed anymore (m files at the root
> of the package and oct in a directory named with API version), pkg did
> not found them.

I will build an INDEX file and check that it solves the problem with 
generate_package_html.

> 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.)