[Pkg-octave-devel] Dynare

[Sébastien Villemot]

Le mardi 24 mars 2009 à 14:26 +0100, Rafael Laboissiere a écrit :
> I quickly reviewed your work.  It is nearly perfect, thanks for that.  I
> fixed some minor issues, most of them detected by Lintian.  Here are some
> further points that should be addressed:

Thanks for taking the time to fix my mistakes.

> 1) Lintian gives the warning arch-dep-package-has-big-usr-share.  I think
>    that we could put the documentation files in a separate dynare-doc
>    file.  Adding doc-base support would be a plus.

I am going to split the package. Actually there is already some doc-base
support (for the reference manual and the user guide), through
dh_installdocs. Did I miss something?

> 2) The *.m scripts and the *.mex, currently installed in
>    /usr/lib/dynare/matlab/ and /usr/lib/dynare/mex/octave/, respectively,
>    should be put in the Octave's path.  I will take a look at this later.

Do you mean installing the files somewhere else than in /usr/lib/dynare,
or automatically adding the relevant directories to the path variable of
Octave? If you meant the latter, note that only /usr/lib/dynare/matlab
needs to be added, since it contains dynare.m which is the main entry
point. Dynare then manipulates the path (see dynare_config.m) to add the
other directories.

> 3) Are the empty directories /usr/lib/dynare/mex/2007a/ and 2007b/ really
>    needed?

These directories are used to store the MEX files when the user runs
Dynare from Matlab (and Dynare complains if they are nonexistent). But
they are indeed not needed when Dynare is run from Octave, so I am going
to remove them.

For Matlab users I will later create a postinst script which will create
these directories on the fly, and compile the MEX files, if the user
requests it.

> 4) Some bashisms in the upstream Makefiles should be fixed. For instance,
>    in doc/preprocessor/Makefile, I see:
> 
>        clean:  
>                rm -f preprocessor.{pdf,toc,aux,log,nav,snm,vrb,out} *~
>    
>    When using a POSIX-compliant shell like dash (this is what I use in my
>    sid chroot), the package does not clean properly and is not
>    idempotent. Please, fix.

Thanks for pointing this.

> 4) Is there a test suite that can be exercised during the package build?
>    It is always good to have one, such that we can detect problems before
>    uploading the package.

No, unfortunately we don't have any automated testsuite. This is
definitely on our todolist, however.

Best,

Sébastien