Re: [Enigma-devel] Windows MinGW/MSYS Development

[Ronald Lamprecht]

Hi,

Ivan Wick wrote:
> Hi Developers,
> I spent some time getting familiar with the Enigma source code and
> getting a build environment set up on Windows XP.  I am using the
> latest stable versions of MinGW and MSYS, and was working with
> revision 1167 of the subversion trunk.  I have a few questions:

Welcome to the Enigma developer community :-)

Please note that we currently do not use the "stable" MinGW/MSYS 
version. This is due to severe stability problems with this branch on 
exception handling. Please read the thread "[Enigma-devel] Lua 5.1 
"luaL_error" problems on Windows" in June/July 2006 on this group 
(http://lists.gnu.org/archive/html/enigma-devel/) for more background 
information.

When I settled the tool chain for the upcoming 1.10 release in last 
summer the current "stable" MinGW version was still the upcoming relase 
and did show problems. I did not check the stability afterwards - this 
is still on my TODO list. A compilation without errors and successful 
running of stable Enigma revision is not a sufficient criteria. You need 
to test the behaviour on errors - errors in Lua code and errors within 
the C++ engine.

Thus the trunk is configured for the last MinGW/MSYS release as 
described in the doc/REQUIREMENTS file.

> - Configure script in MinGW
> I encountered a couple of problems with using the configure script to
> compile under MSYS.  For instance, the following (configure.ac:174):
>
> if test "$MINGW32" = yes; then
>   AC_MSG_CHECKING([for Xerces 3.0 experimental version])
>   AC_EGREP_HEADER([gXercesMajVersion = 3],[xercesc/util/XercesVersion.hpp],
>       [AC_MSG_RESULT([found])],
>       [AC_MSG_ERROR([not found])])
>    AC_CHECK_LIB(xerces-c, main,,[AC_MSG_ERROR([xerces is required to
> compile Enigma])])
> else
>
> will make the generated configure script fail on MinGW when not using
> Xerces 3.0 expeimental version.  I was able to get it working with
> Xerces 2.8 after commeting this out.  Should this be changed?

Xerces 2.8 has problems with the last MinGW. As Xerces 3.0 is better and 
much more stable than 2.8, I do see no reason to support it for Windows. 
I do expect the 3.0 release anyway in this summer. We just need to 
support the old 2.* releases for existing Unix installations.

> The code relies on libcurl, which was also not detected under
> MinGW/MSYS without the following change (configure.ac:203), because
> the libcurl development binary I downloaded (libcurldll instead):
>
> dnl ----------------------------------------
> dnl Check for libcurl
> dnl ---------------------------------------
> if test "$MINGW32" = yes; then
>     AC_CHECK_LIB(curldll,curl_global_init,,[AC_MSG_ERROR([libcurl is
> required to compile Enigma])])
> else
>     AC_CHECK_LIB(curl,curl_global_init,,[AC_MSG_ERROR([libcurl is
> required to compile Enigma])])
> fi

I had no success with the available dll versions and the last MinGW 
release. Thus I did prefer to compile libcurl with MinGW which did 
result in a dll that does link without problems.

> I didn't want to submit a diff straight away because this is the first
> time I have set up this build environment on Windows and I am not
> certain if it am correctly differentiating between errors in
> configure.ac from any errors I might have made in setting up
> MinGW/MSYS.  Have any Windows developers had similar experiences?

I would really appreciate if someone with background knowledge would 
perform the necessary checks with the current stable MinGW/MSYS release. 
But I think this tool switch would be true for the upcoming 1.20 branch. 
You would really need to convince me of the stability for a switch of 
the trunk in the current development stage of 1.10.

> - Visual C++
> Trunk has a VisualC directory in it with project files, etc, but it is
> outdated.  What is the current status of using Visual C++ to compile
> Enigma?  Is someone working on getting it updated to the current
> sources?  If not, I will make an attempt to get it working in Visual
> C++ 9.0 Express Edition.

Daniel did set up these Visual C++ files after the 0.92 release when he 
faced stability problems with MinGW. At that point we fixed some C++ 
compatibility issues, too. But due to the workload we did not maintain 
the project files.

As nearly all development work from the core team is done under Linux it 
is generally difficult to maintain such files. But in principle I do 
like the idea of updating and keeping compatibility to Visual C++.

Currently we do a lot of reengineering work. Thus the files and 
directories do change daily. Even the VisualC directory is subject of 
being moved to a more standard path like "Projects/Win32/VC*". I would 
suggest starting with such an update when we reach the alpha release of 
1.10. But feel free to check the current trunk for Visual C++ 
compatibility and report any C++ issues.

Greets,

Ronald