Re: Path treatment issue Octave on mingw : pkg.m

[Benjamin Lindner]

> Dear sirs,
> 
> I'm have been trying to build Octave 2.9.13.  As reported
> previously, it worked well in preliminary sense.  The
> speed for built binary was sufficient.
> I'm now working mkoctfile and pkg commands.

Excellent. Good to see that there is effort on the mingw32 topic.
 
> The mingw octave have been of course on msys environments.
>   The msys treats the path name in unix like style.  While
> the built octave binary returns the windows like path.
> 
> The functions octave on mingw binary return the path in
> windows style.  For example, OCTAVE_HOME () returns
> 
> C:\Programs\msys\1.0\local\octave-2.9.13
> 
> In the revise of mkoctfile.m, the script was very simple,
> the problem was solved easily.
> 
> I have read 'pkg.m', it is complicated so I have not
> understand how it works yet.  Does 'pkg.m' require the 
> posix like environments?  If so I have to write a function
> to get the msys path from the window path. 

Hmm, which problem are you experiencing?
I have also built using msys environment and it worked for me, and I 
didn't require special path-converting tools, so I don't know of any
traps right now.
According to my experience the msys environment automatically converts 
the paths to the required form.

Have you tried to run the configure script of a sample package seperately?
Just unpack the package and run configure from within a msys shell (you
have to make sure that the octave's mkoctfile is found in the path, of
course.)
Then you can seperately check and run 'make' and see if this works.

If this shows no errors, then try to run the same procedure from within
octave by issuing the commands via system().

Maybe it is a issue of mixing mingw32 and msys utilities due to the
order of directories in the PATH environment?


benjamin

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger