corrected output typo

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2108 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
corrected output typo

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2109 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
fixed typo in sIpopt's AMPL interface (reported by Weifeng Chen)


git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2110 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
contributed by Tony Kelman: improvements to Matlab recognition in configure and build of Matlab interface

Following Tony's description of this patch:

Overall, I see that configure has a section regarding the Matlab interface,
but much of the time (especially on Windows or Mac) it does not do the job
entirely and users have to make manual modifications to the Matlab interface
Makefile along with mexopts.sh (.bat on Windows). My goal with this patch is
to at least eliminate the need to modify the Makefile, for as many cases as
possible.

The existing configure section for the Matlab interface tries to
automatically look for the Matlab installation location with a "which"
call, but many recent Matlab versions (for Linux) have moved away from adding
the $MATLAB_HOME/bin directory to the system path, and towards adding just a
few symbolic links in /usr/local/bin. So mexext is rarely on the path
anymore, but matlab frequently is - often as a symbolic link. I've changed the
"which" commands to look for matlab accordingly, and in the case of
symbolic links, read where they point to ($MATLAB_HOME/bin/matlab). I'm not sure
whether my `ls -l "$mexpath" | awk '{print $NF}'` is more or less
preferable/portable than using readlink. I also added a few quotes
anywhere $MATLAB_HOME gets used, in case the Matlab path has spaces in it (common
in Windows - could get or require the user to provide the short PROGRA~1
style name, but I don't think it's necessary).

On Windows, Matlab is more frequently on the path. The behavior of
"which" is inconsistent between Cygwin and MSYS for executable names: Cygwin
returns the location without the .exe extension if the input does not end with
.exe, whereas in MSYS "which matlab" returns "/c/path/to/matlab.exe" or
similar.
If you ask for "which matlab.exe" on the other hand, both Cygwin and
MSYS return the location including the .exe at the end. So I've added $EXEEXT
in the "which" command and the sed call that removes /bin/matlab.exe from
the end of the "which" result. This will make no difference for Linux or Mac
users, when $EXEEXT is empty.

On Windows, the mex and mexext utilities are batch files, so we need to
add .bat in order to find them. MSYS can't execute batch files natively, so
I use cmd /c to call mexext.bat for MinGW.

The mex compiler doesn't understand Apple-style flags like "-framework
vecLib." Ray Zimmerman's "Ipopt on Mac OS X" wiki page has a step where
he says to remove "-framework vecLib" from the LIBS line of the Matlab
interface Makefile, and to add it to LDFLAGS in mexopts.sh. I've added a
sed call in contrib/MatlabInterface/src/Makefile.in to remove it from LIBS
automatically. Rather than adding it to LDFLAGS in mexopts.sh, it can be
added to LDFLAGS in Makefile.in. I've added an AC_SUBST variable to do
that, defined in configure by grepping $BLAS_LIBS and $LAPACK_LIBS for
"-framework vecLib". This way the user doesn't have to mess with mexopts.sh as
often.

There can still be problems on Mac since Mathworks hardcodes an expected
Xcode version in $SDKROOT, which may not be installed. That's not
necessarily configure's job to fix, but it could be. I have a
post-configure script that copies the default mexopts.sh from its location in
$MATLAB_HOME/bin, tests whether or not the expected $SDKROOT directory
exists, and makes the necessary modifications if it doesn't.

On Windows, mex doesn't recognize the -cxx flag. I get rid of it
selectively using a new AM_CONDITIONAL, MEX_WINDOWS. I also use the same conditional
to modify the setting of MEX to call Matlab's included Perl on
$(MATLAB_HOME)/bin/mex.pl. There are a few more quotes and a CYGPATH_W
call in there to handle Matlab paths with spaces, and paths returned from
"which" that are in /cygdrive/c/path format. I was a little worried about the
win32 in the path to Perl, but turns out even 64-bit Matlab includes a 32-bit
version of Perl at that path.

I've tested this set of changes pretty extensively on Linux, Mac, Win32,
Win64, Cygwin, MinGW32, MinGW64, with and without Matlab, various
combinations of specifying --with-matlab-home as a configure flag with
different directory formats, or letting configure find Matlab via
"which."
It works as expected, or at least better than the existing version, in
every test I could come up with.

On Windows this patch by itself is not enough to get a functioning mex
file, but the only missing piece should be mexopts.bat generated by Gnumex
(http://sourceforge.net/projects/gnumex/) then modified appropriately.
The post-configure script I have does all this, but I imagine automatically
downloading Gnumex could be problematic due to the differing licenses.
It might be too OS-specific to add as a ThirdParty/Gnumex/get.Gnumex, but I
could contribute the remaining pieces in that form if there's interest. 



git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2111 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
by Toni Kelman: automate some steps for building mex files on Mac and Windows

This adds get.Gnumex to /Ipopt/contrib/MatlabInterface along with a patch
I wrote to make Gnumex work on Win64 Matlab.

Gnumex doesn't need to build any executables, it runs from inside
Matlab. It comes with some mexw32 files, and part of my patch tries to
build the mexw64 equivalents from inside Matlab (if 64 bit), or uses a
different workaround if that fails. I added a gnumex target in
Makefile.in to open an instance of Matlab and run Gnumex (or echo a
warning with instructions if the user hasn't run get.Gnumex yet) with
some of the options filled out to recommended settings. If Cygwin and/or
MinGW are installed in default locations, the user should only need to
click "Make options file" then exit the new instance of Matlab (so we
know Gnumex is finished).

The new mexopts target in Makefile.in makes the Mac or Windows
modifications to mexopts.sh or mexopts.bat. I added it as a recursive
make call in the $(TARGET) rule, since adding it to the dependencies
would make "mexopts" show up on the compilation command line from "$^".
We could alternately have "make mexopts" always be a manual step for Mac
and Windows users.

For Mac, if there is not currently a mexopts.sh file in the Matlab
interface build directory, I look at the default one, test if the
hardcoded $SDKROOT path actually exists, and if not I make a copy with
all references to $SDKROOT removed.

For Windows, I give a warning if no mexopts.bat file is found in the
Matlab interface build directory. This warning message may take a lot of
scrolling to find unfortunately, if the default setup results in really
long error messages from mex. If there is a mexopts.bat in the build
directory, I add $(LIBS) to GM_ADD_LIBS, change COMPILER=gcc to
COMPILER=g++, and GM_MEXLANG=c to GM_MEXLANG=cxx. I need to modify -L
flags from $(LIBS) to Windows format directories, although forward
slashes work and prevent having to double/quadruple/octuple backslashes
for future sed calls. I do this using "cygpath -m" on $(libdir) and
/usr/lib in Cygwin, or using a fairly ugly cmd /c DOS for-do-@echo call
in MinGW (only on libdir).

An annoyance in Cygwin is that due to the alternatives system, g++ is a
symbolic link to either g++-4 or g++-3. This causes "Access is denied"
errors when linking mex files, so on Cygwin I use g++-4 for COMPILER, or
g++-3 if the former is not on the path, or g++ if neither g++-4 or g++-3
is on the path.

Results:
Linux - no change, except more output to the screen when going through the no-op make mexopts.

Mac - working mex file when configured with --disable-shared, but
crashes Matlab without. The shared-library version gives a malloc error,
"pointer being freed was not allocated," in
IpoptOptions::useQuasiNewton, Ipopt::OptionsList::GetStringValue,
std::string::assign. This is probably a libstdc++ incompatibility issue.

MinGW32 - works very nicely with no configure flags needed (../configure
&& make install test && cd Ipopt/contrib/MatlabInterface/src && make
gnumex install && echo done)

MinGW64 - works with the configure flag ADD_FFLAGS=-static-libgcc, this
prevents a "multiple definition of `_Unwind_SjLj_Unregister'" error when
using the TDM-GCC distribution of MinGW64.

Cygwin - compiles mex file successfully, but freezes Matlab when
configured with --disable-shared, crashes Matlab without. The
freeze/crash is extremely difficult to debug, I couldn't even get any
output by adding a printf at the very beginning of mexFunction in
ipopt.cpp. 



git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2112 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
fix bug when compiling sIPOPT without AMPL interface 

(Thanks to Joel Andersson for spotting this)


git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2113 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
Bigfix for segfault reported by Tony Kelman

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2114 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
fix for bug reported by Nick Sahinidis: In case of catastrophic failure in restoration phase, no iterate might be available to be returned to the user.  This is to avoid seg faults in this case.

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2115 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
changed default for dependency detection threshold

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2116 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
setup rhs for mehrotra only if affine deltas are available, fixes part of #114

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2122 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
flip sign of lambda in dual solution reported to ampl, fixes #183

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2123 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
update my affiliation; fix typos; add Tony

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2125 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
rerun autotools

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2126 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
undo r2122, issue from #114 was probably fixed by r2114 already

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2127 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
missing part of r2125

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2130 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
fix r2123 (thanks to watchful Tony)

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2131 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
Tony's fix from #187: fix behavior of matlab interface when using sparse gradients, fix issue with options input without ipopt field

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2133 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
merge r2129 and r2135 from stable/3.10: updates to changelog

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2136 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
patch by Jonathan Currie (assembled by Tony Kelman): include number of functions evaluations into info output, tweak to disable ipopt output

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2140 ef2a96d0-92f8-0310-a3c1-cdaa70078a94
add modified version of Tony Kelman's patch from #186: allow to change integer type for MA57 to long, useful when using Matlabs MA57 library

git-svn-id: https://projects.coin-or.org/svn/Ipopt/trunk@2141 ef2a96d0-92f8-0310-a3c1-cdaa70078a94