To enable @#include to be easily used with libraries of utilities e.g. https://github.com/tholden/DynareTransformationEngine , it needs to be able to include MOD files that are not in the current folder, and are instead somewhere in the MATLAB path. Copying and pasting is both messy and unreliable.
@#include does not have access to the Matlab path as this is in the macroprocessor. You need to include the entire path in the @#include statement to find the .mod file.
Using a relative path is a good idea, but it still doesn't solve the issue. It would be nice to be able to use libraries of mod files, like libraries, and for that, scanning some path is necessary.
It wouldn't be hard to give the preprocessor access to the MATLAB path, so I don't think that's really an answer or a reason for closing this ticket. The question is whether the preprocessor ought to have access to the MATLAB path. And I'd argue that the answer to that is "yes".
we should probably explore the entire path and report an error if two *.mod files have the same name
Logically *.mod files are different from Matlab file, why use the Matlab path and not a Dynare path?
If you are into libraries of *.mod file, you probably also have libraries of *.m files for pre or post processing. Maybe we should encourage users to keep same in separate directories. That would argue in favor of a Dynare path
By design, the Dynare macrolanguage is unMatlab (double quote for strings, ! for not, ...) in order to limit confusing between the macro language and Matlab. Using the same path would depart for that logic
A Dynare path would be shorter and faster to visit
I am also not in favor of including the whole Matlab path.
There is a command line option to the preprocessor to define macro variables (-DMACRO_VARIABLE=MACRO_EXPRESSION). We could add the possibility to specify paths to folders where the preprocessor would search for files (not necessarily *.mod files by the way) to be included. Something like:
-I/home/user/lib/dynare/rototo
This is what is done for *.h files with compilers like gcc.
Thanks a lot for the -I contribution. That does solve the problem, and it sounds like Michel's INCLUDEPATH suggestion will be very helpful too.
One further suggestion: Just as MATLAB/GCC/whatever have a few default folders they always include, it might be nice for Dynare to have one or more directories it always includes too? Perhaps ~/DynareInclude/ (if it exists) and DYNARE_ROOT/DynareInclude/ ?
@tholden the decision was made to allow for paths to be specified in the dynare config file which is automatically read every time dynare is run. So, if you want to include a directory, it's sufficient to add the following to your dynare config file: