Normally, the configuration and compilation of Meep and its dependencies require the GNU toolchain. As it is not practical to setup a Linux on my new Laptop, it was necessary for me to port meep to Windows.
Compiling in Cygwin should be the easiest work. That does not require any additional package nor to change the Meep source code. However, I would wish to have a native port of the library in windows for the debugging and other purposes. To achieve that, the cross compiling of Meep under Cygwin for Mingw is an option.
Why not use the Mingw in MSys directly? MSys lacks of several tools at the time of writing: git, cmake, pkg-config, manpages and documents. Although one could install them into MSys manually, it is not practical and will take extra time and work. Compared to MSys, Cygwin works more like Unix, for example, the symbolic link does not exist in MSys, but one can find the symbolic link in Cygwin, which is implemented either as a special system file or a windows shortcut.
Meep, guile, hdf5, blas/lapack, harminv, gmp, libctl, fftw3, and several
dependency can be cross compiled from Cygwin to Mingw. In the cross compiling,
the path name translation was the only problem: Mingw programs do not
understand Cygwin path, on the other hand, the GNUMake in Cygwin cannot use an
absolute windows path as dependence (say that there is a target
C:/foo.obj
, make.exe will misinterpret the C:
as a
strange rule). By wrapping path names and some environment variables e.g.
GUILE_LOAD_PATH
with the command cygpath
as well as
using the libtool
naming rules, this issue can be solved. The
libctl
feature was dropped since there was no plan for me to use
that.
Now, the programs and even the Meep code itself can be developed and debugged within the recent Visual Studio.