RE: MSVC compiler patches

[John W. Eaton]

On  2-Nov-2006, address@hidden wrote:

| > * A short guide to let people know what needs to be done to build
| > Octave with MSVC. I think it would help to have a list of exactly where
| > to look for the compiler, which MSYS package(s) need to be installed,
| > etc.
|  
| Here's a first draft of a compilation guide under MSVC.

Thanks for working on this.  I installed it in CVS as README.MSVC with
some minor changes.  I moved the contents of README.Windows to
README.Cygwin and made README.Windows refer to the README.MSVC and
README.Cygwin files.

If you have additional changes, please send diffs relative to the
current CVS version.

Here are a few comments:

  1.4 Unix-to-MSVC compilation scripts
  ------------------------------------

  These scripts provide a UNIX-like compilation interface, based on the
  Microsoft compilation tools.  The package is available from the Octave
  web site.

We haven't put anything in place yet.  Which scripts do we need to
make available from the web site?  If they are required by Octave the
build process, then maybe we should include them with the Octave
sources?  Is it just the cccl script?

  1.5 Glob library
  ----------------

  Octave also requires a filename globbing library.  This library is
  typically part of the C library on UNIX systems, but is not part of
  the Windows or MSVC run-time libraries.  You can find a glob package
  on the Octave website.

OK, I need to do this.

  1.6 Readline library
  --------------------

  While not mandatory to compile Octave, the readline library is very
  useful to make Octave really usable.  A patched version of the
  readline library can be found in the Octave website.

Do I have the diffs for readline?

  1.7 F2C
  -------

  As there exist no free MSVC-like fortran compiler, the compilation
  process makes use of the f2c utility and the libf2c library.

Shouldn't it be possible to use g77 or gfortran to compile the Fortran
bits?

  2. Compilation
  ==============

  Copy the following lines into a shell script and execute it (note that
  you can use whatever you want as installation directory):

  --- BEGIN (cut me)
  #!/bin/sh
  if ! grep "__declspec(noreturn dllimport)" configure 2>&1 > /dev/null; then
    echo "Pre-processing configure script..."
    sed -e "s/'extern \"C\" void exit (int);'/'extern \"C\" __declspec(noreturn 
dllimport) void exit (int);' 'extern \"C\" void exit (int);'/g" configure \
      > configure.tmp
    mv configure.tmp configure
  fi

What is the purpose of doing this?

  CC=cc-msvc CXX=cc-msvc NM="dumpbin -symbols" AR=ar-msvc RANLIB=ranlib-msvc \
    ./configure --build=i686-pc-msdosmsvc --prefix=/usr/local/octave-vc8-debug 
--with-f2c

Since this last line just sets a variable in a shell script, I don't see
that it has any effect.  At least on Unixy systems, executing a shell
script can't have any effect on the parent environment.

If running this script is necessary, then shouldn't this be included
as part of the Octave build process instead of hidden in a README
file?

  2.1 MSYS
  --------

  When building from the MSYS shell and CVS, everything should run fine
  until building the doc.  At some point, TeX might ask you for the
  location of the file conf.texi.  If this happens, simply type
  "../conf.texi" and the process should continue.

Is this a bug in the texi2... scripts?  If so, we should probably
report it.

  2.2 Cygwin
  ----------

  Building from the Cygwin shell and CVS produces more compile-time
  errors when generating the documentation.  Here are some fixes that
  should work around most problems:

    * edit "run-octave" and add the 2 lines right after the definition of
      LOADPATH and IMAGEPATH:

        LOADPATH=`cygpath -d -p $LOADPATH`
        IMAGEPATH=`cygpath -d $IMAGEPATH`

We could just add these lines to the script.  They would need to be
added only when appropriate though, and I'm not sure what is the right
condition to check.

  3. Installation
  ===============

  The compiled Octave is relocatable.   This means that whetever
  installation dir you chose at configure time, you can move the whole
  installation directory to another location without any problem.   Octave
  should still run OK.

There are still some problems with this.  The variables in
octave_config_info need to have OCTAVE_HOME substituted appropriately,
and we need to have a solution for the scripts like mkoctfile and
octave-config that also rely on paths.  In another message, I asked:

  * OCTAVE_HOME substitution.  We need to fix this for all the
    scripts, not just the octave_config_info function.  This is not a
    high priority for me at the moment because it isn't needed to
    actually make Octave work provided that you install it in the same
    location used to compile it.  Would it be reasonable to require
    that OCTAVE_HOME is set in the environment if Octave is installed
    in a directory tree other than the one specified at compile time?
    If so, should we expect users to do this by hand, or should we
    have a program that does it for them (modifies the registry?).

and I haven't seen any comments from anyone about this yet.


jwe