Major Changes from 9.0.65 * ADMB setup windows setup files using Inno Setup Software (http://www.jrsoftware.org/isinfo.php) * Added support for more compilers - Microsoft Visual C++ 2005 (32 bit) - Microsoft Visual C++ 2008 (32 bit) - Linux Gcc 4.1.2 (32 and 64 bit) - Linux Gcc 4.2.4 (32 and 64 bit) * Corrected issues with windows batch files
> Major Changes from 9.0.65 > * ADMB setup windows setup files using Inno Setup Software (http://www.jrsoftware.org/isinfo.php) > * Added support for more compilers > - Microsoft Visual C++ 2005 (32 bit) > - Microsoft Visual C++ 2008 (32 bit) > - Linux Gcc 4.1.2 (32 and 64 bit) > - Linux Gcc 4.2.4 (32 and 64 bit) > * Corrected issues with windows batch files
----- Original Message ----- From: Arni Magnusson <arn...@hafro.is> Date: Tuesday, April 21, 2009 3:55 pm Subject: Broken tpl2cpp in Windows To: Johnoel Ancheta <john...@hawaii.edu>
Cc: Hans Julius Skaug <Hans.Sk...@math.uib.no>, John Sibert <sib...@hawaii.edu>, Anders Nielsen <and...@nielsensweb.org>, Mark Maunder <mmaun...@iattc.org>
> > tpl2cpp simple > 'cat' is not recognized as an internal or external > command, operable program or batch file. > Error trying to create output file simple.cpp
> The tpl2cpp program has run independent of cat in all previous > ADMB > release, and I hope it will continue to do so. In my opinion, we > shouldn't > force the user to install anything except the ADMB core and a > compiler. > [For the same reason, I think asking the user to install > gnuwin32 make > adds an unnecessary layer of complexity, since the traditional > makeadm > simple is all that's required to test the installation - but we > can save > that discussion till later. The examples/admb/Makefile is of > course a > great bug test for the development team, on the other hand.]
> This problem with tpl2cpp.exe is a Windows feature and therefore > partly on > my watch, but I haven't figured out what has to be changed in > the sources > to make it independent again. A quick fix is to copy tpl2cpp.exe > from > http://admb-project.googlecode.com/files/admb-9.0.65.2-mingw32- > gcc3.4.5.zip > and release a patched version.
I finally found the problem. The broken tpl2cpp in ADMB for MinGW gets created from the call:
gcc -I. -DUX mylex.c -otpl2cpp
The -DUX should only be used when compiling mylex.c->tpl2cpp on Linux. In mylex.c, Dave Fournier defined a macro called UX that helps the compiler choose the right lines of code, depending on whether mylex.c is being compiled on Windows or Linux. By using -DUX it calls things appropriate for Linux, while bypassing the code intended for Windows. In other words, a healthy tpl2cpp for MinGW should be created with the call
gcc -I. mylex.c -otpl2cpp
or better still
gcc -s mylex.c -o tpl2cpp
for a leaner executable.
---
The problem lies in mingw.mak, which currently calls optg32-rh8-laplace.mak. As the name implies, the latter makefile is intended for Red Hat 8 Linux and is therefore not appropriate for making ADMB for Windows.
The solution is to edit mingw.mak so that it calls a makefile intended for making ADMB for Windows. This is a much better solution than making ADMB for Windows dependent on cat.exe. Dave Fournier already did the hard work creating the UX macro to make ADMB for Windows self-contained.
The same corrections need to be made for tpl2rem, which also uses Red Hat 8 Linux makefiles. It looks like the Windows makefiles will be very similar, except no -DUX.
----- Original Message ----- From: Arni Magnusson <arn...@hafro.is> Date: Wednesday, April 22, 2009 6:40 am Subject: Re: Broken tpl2cpp in Windows To: Johnoel Ancheta <john...@hawaii.edu>
> I finally found the problem. The broken tpl2cpp in ADMB for > MinGW gets > created from the call:
> gcc -I. -DUX mylex.c -otpl2cpp
> The -DUX should only be used when compiling mylex.c->tpl2cpp on > Linux. In > mylex.c, Dave Fournier defined a macro called UX that helps the > compiler > choose the right lines of code, depending on whether mylex.c is > being > compiled on Windows or Linux. By using -DUX it calls things > appropriate > for Linux, while bypassing the code intended for Windows. In > other words, > a healthy tpl2cpp for MinGW should be created with the call
> gcc -I. mylex.c -otpl2cpp
> or better still
> gcc -s mylex.c -o tpl2cpp
> for a leaner executable.
> ---
> The problem lies in mingw.mak, which currently calls > optg32-rh8-laplace.mak. As the name implies, the latter makefile > is > intended for Red Hat 8 Linux and is therefore not appropriate > for making > ADMB for Windows.
> The solution is to edit mingw.mak so that it calls a makefile > intended for > making ADMB for Windows. This is a much better solution than > making ADMB > for Windows dependent on cat.exe. Dave Fournier already did the > hard work > creating the UX macro to make ADMB for Windows self-contained.
> The same corrections need to be made for tpl2rem, which also > uses Red Hat > 8 Linux makefiles. It looks like the Windows makefiles will be > very > similar, except no -DUX.
Arni Magnusson wrote: > I finally found the problem. The broken tpl2cpp in ADMB for MinGW gets > created from the call:
> gcc -I. -DUX mylex.c -otpl2cpp
> The -DUX should only be used when compiling mylex.c->tpl2cpp on Linux. > In mylex.c, Dave Fournier defined a macro called UX that helps the > compiler choose the right lines of code, depending on whether mylex.c > is being compiled on Windows or Linux. By using -DUX it calls things > appropriate for Linux, while bypassing the code intended for Windows. > In other words, a healthy tpl2cpp for MinGW should be created with the > call
> gcc -I. mylex.c -otpl2cpp
> or better still
> gcc -s mylex.c -o tpl2cpp
> for a leaner executable.
> ---
> The problem lies in mingw.mak, which currently calls > optg32-rh8-laplace.mak. As the name implies, the latter makefile is > intended for Red Hat 8 Linux and is therefore not appropriate for > making ADMB for Windows.
> The solution is to edit mingw.mak so that it calls a makefile intended > for making ADMB for Windows. This is a much better solution than > making ADMB for Windows dependent on cat.exe. Dave Fournier already > did the hard work creating the UX macro to make ADMB for Windows > self-contained.
> The same corrections need to be made for tpl2rem, which also uses Red > Hat 8 Linux makefiles. It looks like the Windows makefiles will be > very similar, except no -DUX.
