|
From: | Julien Bect |
Subject: | Re: Requirements for releasing the STK toolbox as an Octave forge package ? |
Date: | Mon, 24 Feb 2014 17:57:06 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
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.)
[Prev in Thread] | Current Thread | [Next in Thread] |