RE: Re: MSVC compiler support [patch 27]: OCTAVE_HOME

[John W. Eaton]

On 25-Oct-2006, address@hidden wrote:

| > How about this version instead? It should avoid the arbitrary limit.I'm 
assuming that the 
| > GetModuleFileName will eventually succeed if thebuffer is large enough. Is 
there any 
| > other reason that it could fail?
| 
| I don't know, but probably not in normal cases. I tested your patch, it 
contains an error
| in the bin_dir string initalization: the char and size argument should be 
swapped. Otherwise,
| it works fine.

Oops.  I fixed that.

| > Also, I'm assuming that this code can be used with MinGW, 
| 
| Yes. But I don't know which path semantic is expected by the MinGW version of
| octave (/usr/bin/octave.exe or 
C:\\Where\\MinGW\\is\\installed\\bin\\octave.exe)
| 
| Note also that there's still a mismatch between the path values used in 
defaults.cc and
| the ones presented in octave_config_info(), because the latter does not use
| OCTAVE_HOME.

OK, this problem could probably be fixed for Octave itself, but what
about the support scripts like octave-config, octave-bug, or
mkoctfile?  They all use similar substitutions, and none are adjusted
for OCTAVE_HOME being different that what was used at configure time.
I can also see fixing the scripts by looking at the value of
OCTAVE_HOME in the environment and doing some substitutions, but your
changes to Octave allow it to be moved without requiring the user to
set OCTAVE_HOME in the environment, so we need a way to deal with
that.  Perhaps we should write octave-config in C++ and use that to
provide properly transformed configuration values to the scripts.

Finally, what do we do with the scripts on Windows?  Do we assume that
there is a Bourne shell available to run them, or do we want to
replace them with something else?

jwe