Note that the timestwo.F example that comes with MATLAB is a bad example of Fortran code. It has several bugs in it that could lead to a crash, such as:
- Does not check if the input type is double
- Does not check if the input type is sparse
- Does not check if the input type is complex
- Copies arrays of numbers into a scalar location
- Reads arrays of numbers from a scalar location
- Uses 'size' for a variable name even though this is a Fortran intrinsic function name
- Comments are lined up with code, making it very hard to read
- Uses mwPointer type for mrows and ncols even though doc states the type should be mwSize
- Passes a literal 0 to an API function when a variable of type integer*4 should be used per the doc
I have given these issues to the TMW folks but nothing seems to have been done about it. I think I need to create my own version of this routine and post it in Answers for people to see the corrected code. The matsq.F file has similar problems that can crash MATLAB, but at least it tries to get the array stuff protected (even though it employs two completely unnecessary deep data copies in the process).
Getting back to your original question, if the subroutines are in the same file then just compile as normal. If the subroutines are in different files then just list those file names next to your main file name in the mex command. I.e.,
mex mymain.F mysubroutine1.F mysubroutine2.F
You can also precompile code and then just list the object files in the mex build. E.g., on Windows you could do this:
The above lines compile the subroutine files into object files, but does not try to link them. Then later on you can compile your main routine into a mex function using these object files instead of the original source files:
mex mymain.F mysubroutine1.obj mysubroutine2.obj
This technique can be useful if you are debugging and modifying mymain.F several times inbetween testing as it can speed up the mex routine build process.
