"Rafael Laboissiere" <rafael@debian.org> a écrit :
I looked more closely into the package structure. I think it is possible to make two minimal changes in order to get it working out of the box for Octave. The first change regards putting dynare_config in the Octave's. The patch for debian/rules that do this respecting the guidelines of the DOG is attached below.
Thanks for having looked closely at the package, and for pointing me to the $(MDIR) directory.
Actually dynare_config.m runs no computation, but only does some path manipulations. So if I we adopt your suggestion, the user would first have to run "dynare_config" once in an Octave session, then do its computations using "dynare" (the top-level function).
Another solution would be to directly put dynare.m in $(MDIR), which would allow users to run Dynare with one command instead of two.
I think I prefer the second solution, but maybe you have objections to that one?
Second, dynare_config.m must itself be patched in order to have: dynareroot = '/usr/lib/dynare/matlab/' There is another thing that can be improved in the package. All the .m files are installed in /usr/lib/dynare/matlab/. According to the FHS [1], such architecture-independent files must be installed in /usr/share instead. If this is done, the dynare package should be split into a dynare package containing the .mex files and a dynare-common package with arch:all containing the .m files. This is done with octave3.0 and octave3.0-common, BTW.
Both of these changes are already done. The only arch-independent file which is still in the main "dynare" package is /usr/lib/dynare/mex/octave/rcond.m, which is meant to provide a rough replacement for "rcond" which is present in Matlab but not in Octave 3.0 (I think it will be in Octave 3.2). Maybe should I move this file to $(MDIR) ? (I don't want it in /usr/share/dynare/matlab because of Matlab users, and putting it into /usr/share/dynare/mex/octave makes no real sense)
All the best, -- Sébastien Villemot