Got Questions? Get Answers.
Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
simple mex file issue

Subject: simple mex file issue

From: Mateusz Gos

Date: 20 Jul, 2011 15:22:10

Message: 1 of 5

Hi,

I am compiling a mexw32 file from an .f90 file. The mexw32 uses additional files. For that I need to specify where it should look for them and hardcode it into f90 file before compiling. Problem I have is that I must put the additional files in the same directory as the mexw32 file, so the hardcoded path must point into the 'current' folder.

I though base_dir='.\' should work but it doesn't. Can someone please advice?


Regards,
Michal

Subject: simple mex file issue

From: Jan Simon

Date: 20 Jul, 2011 23:13:10

Message: 2 of 5

Dear Mateusz,

> I am compiling a mexw32 file from an .f90 file. The mexw32 uses additional files.

Does this mean that the Mex reads any data from a file? Or are the files needed for the compilation?

> Problem I have is that I must put the additional files in the same directory as the mexw32 file, so the hardcoded path must point into the 'current' folder.

The current folder is *not* the parent folder of the Mex file. You can use WHICH to determine the parent folder of a function. But there should be a better location to store data.

Kind regards, Jan

Subject: simple mex file issue

From: Mateusz Gos

Date: 21 Jul, 2011 00:35:12

Message: 3 of 5

First of all - thank you very much Jan.

Addressing your first question - what I meant is that the COMPILED mex file is using additional files to perform calculations for given inputs. Please trust me this is the best way it could be arranged (and it works nicely as long as these files stay in the designated subfolder in which case the hardcoded path is say 'addFiles\').

Thank you for the clarification. The reson why I was thinking about something like '.\' was because it MUST be flaxible. Finding the directory using PWD or WHICH will not help in this case because it will only be valid on a given, single machine and this mex file must work also when moved to a different computer. I thought if I put everything to one folder and tell mex file to use 'same directory as it is in, whatever it may be' it will solve the problem.

Any idea how to do it?


Thank you in advance,
Mat



"Jan Simon" wrote in message <j07ne6$1rd$1@newscl01ah.mathworks.com>...
> Dear Mateusz,
>
> > I am compiling a mexw32 file from an .f90 file. The mexw32 uses additional files.
>
> Does this mean that the Mex reads any data from a file? Or are the files needed for the compilation?
>
> > Problem I have is that I must put the additional files in the same directory as the mexw32 file, so the hardcoded path must point into the 'current' folder.
>
> The current folder is *not* the parent folder of the Mex file. You can use WHICH to determine the parent folder of a function. But there should be a better location to store data.
>
> Kind regards, Jan

Subject: simple mex file issue

From: Mateusz Gos

Date: 21 Jul, 2011 00:53:09

Message: 4 of 5

PS - I might add that trying to put the WHICH or PWD command into the mex file will not work. it has to be a directory of some sort, not a MATLAB command


"Mateusz Gos" <webmaster24@wp.pl> wrote in message <j07s80$d5e$1@newscl01ah.mathworks.com>...
> First of all - thank you very much Jan.
>
> Addressing your first question - what I meant is that the COMPILED mex file is using additional files to perform calculations for given inputs. Please trust me this is the best way it could be arranged (and it works nicely as long as these files stay in the designated subfolder in which case the hardcoded path is say 'addFiles\').
>
> Thank you for the clarification. The reson why I was thinking about something like '.\' was because it MUST be flaxible. Finding the directory using PWD or WHICH will not help in this case because it will only be valid on a given, single machine and this mex file must work also when moved to a different computer. I thought if I put everything to one folder and tell mex file to use 'same directory as it is in, whatever it may be' it will solve the problem.
>
> Any idea how to do it?
>
>
> Thank you in advance,
> Mat
>
>
>
> "Jan Simon" wrote in message <j07ne6$1rd$1@newscl01ah.mathworks.com>...
> > Dear Mateusz,
> >
> > > I am compiling a mexw32 file from an .f90 file. The mexw32 uses additional files.
> >
> > Does this mean that the Mex reads any data from a file? Or are the files needed for the compilation?
> >
> > > Problem I have is that I must put the additional files in the same directory as the mexw32 file, so the hardcoded path must point into the 'current' folder.
> >
> > The current folder is *not* the parent folder of the Mex file. You can use WHICH to determine the parent folder of a function. But there should be a better location to store data.
> >
> > Kind regards, Jan

Subject: simple mex file issue

From: Jan Simon

Date: 22 Jul, 2011 07:46:09

Message: 5 of 5

Dear Mateusz Gos,

> Addressing your first question - what I meant is that the COMPILED mex file is using additional files to perform calculations for given inputs. Please trust me this is the best way it could be arranged (and it works nicely as long as these files stay in the designated subfolder in which case the hardcoded path is say 'addFiles\').

If it is hard coded, it will not be flexible. If you want to keep it flexible to allow moving the tools to another computer, choosing the parent folder of the Mex is a bad idea, because there is *no* direct method to determine the parent folder of the Mex at runtime. Therefore I'm sure, that storing data files in the same parent folder is not a good way and neither the best.
 
The only method to determine the parent folder of the Mex is calling Matlab's WHICH command either from outside the Mex or per mexCallMATLAB.

Kind regards, Jan

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us