I, for example, compile MEX files by calling 'mkoctfile --mex' from outside Octave so I am not sure how separate option parsing could take place.

Concerning the -outdir and -output flags, a backward-compatible way forward could be to do:

• -outdir X: accept
• -output Y: accept, even if Y contains a path (i..e Octave's current behavior)
• -outdir X -output Y: accept if Y doesn't contain a path (or if path is not absolute?)
• -outdir X -output Y: if Y has an absolute path, there's a conflict. Either throw an error or a warning and ignore X.

Not depending on liboctave for mkoctfile might be preferred but the implementation of above would require access to cross-platform equivalents of filesep, fullfile, is_absolute_filename.

Matlab's mex uses the `-outdir` and `output` flags to specify output directory and output filename respectively. Octave's mkoctfile uses the `--output` flag to specify the output filename but it can also be used with a full path.

When implementing `-outdir` in `mkoctfile.in.cc`, what to do if `-outdir` is used as well as `--output' with a full path?

On a side note, can I use functions defined in `file_opts.h` in `mkoctfile.in.cc`?)

@Juan: Yes to the second part of your question.  A missing function should be tagged as a "Feature Request".  "Matlab Compatibility" is where the function exists in Octave and Matlab, but behaves differently between the two.  For example, griddata in Matlab accepts both 2-D and 3-D inputs, wherease Octave's version only accepts 2-D.  This would be an example of "Incompatibility" even though it involves coding a new feature.  Finally, "Incorrect Result" is for something that is just plain wrong.  If the interpreter returned 2 + 2 = 5 that would be "Incorrect".

Maybe we can share some core features so we don't have to maintain two entirely separate functions.  But there are options for mex compatibility (-R2017b, -R2018a, -largeArrayDims, -compatibleArrayDims, -client engine) that don't make sense for mkoctfile.

Rik: Although Octave's mex function is currently built on top of mkoctfile, I'm not sure that makes sense now.  Matlab's mex function accepts a number of arguments now that probably don't make sense for mkoctfile.  Maybe it would be better to split mex and mkoctfile and aim for a compatible mex function?

I do not think this is a feature request. There is at least one instance of code that works in matlab and fails in octave:

https://gitlab.com/hnickisch/gpml-matlab/blob/master/util/minfunc/mex/mexAll_matlab.m

This is a clear matlab incompatibility.

Matlab's mex accepts the outdir option to store the compiled files in a given folder.

Octave's mex accepts output to specify the output name for the mex file that can be used to also set the folder.

Hence implementing outdir seems a matter of just parsing the option and then appending to the output arguments that are currently used. I do not think one should check for the validity of the output name/folder, and I would delegate that to the system utilities to manipulate folders and files.