Improvements to cmake for win32 and other bits.

[carlo-bramini]

I attached here the files that I'm using for compiling fluidsynth with mingw under cygwin as cross compiler.

for example, this line creates the makefiles for 64bit build:
$ cmake ../fluidsynth -DCMAKE_TOOLCHAIN_FILE=../fluidsynth/src/cygwin-cross-mingw-64bit.cmake

Strangely, the 32 bit version worked fine but the 64 bit exe hangs after printing "Type 'help' for help topics." on the console. I just changed the compiler and nothing else, no idea about the cause of the problem. Some debugging will be needed for this.

cygwin-cross-mingw-32bit.cmake:

# Cross compile toolchain configuration based on:
# http://www.cmake.org/Wiki/CMake_Cross_Compiling

# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)

# 32 bit mingw-w64
SET(TOOLCHAIN_PREFIX "i686-w64-mingw32")

# compilers to use for C and C++
FIND_PROGRAM(CMAKE_C_COMPILER NAMES ${TOOLCHAIN_PREFIX}-gcc)
FIND_PROGRAM(CMAKE_CXX_COMPILER NAMES ${TOOLCHAIN_PREFIX}-g++)
FIND_PROGRAM(CMAKE_RC_COMPILER NAMES ${TOOLCHAIN_PREFIX}-windres)
FIND_PROGRAM(PKG_CONFIG_EXECUTABLE ${TOOLCHAIN_PREFIX}-pkg-config)

# path to the target environment
SET(CMAKE_FIND_ROOT_PATH /usr/${TOOLCHAIN_PREFIX}/sys-root/mingw)

# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)

cygwin-cross-mingw-64bit.cmake:

# Cross compile toolchain configuration based on:
# http://www.cmake.org/Wiki/CMake_Cross_Compiling

# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)

# 64 bit mingw-w64
SET(TOOLCHAIN_PREFIX "x86_64-w64-mingw32")

# compilers to use for C and C++
FIND_PROGRAM(CMAKE_C_COMPILER NAMES ${TOOLCHAIN_PREFIX}-gcc)
FIND_PROGRAM(CMAKE_CXX_COMPILER NAMES ${TOOLCHAIN_PREFIX}-g++)
FIND_PROGRAM(CMAKE_RC_COMPILER NAMES ${TOOLCHAIN_PREFIX}-windres)
FIND_PROGRAM(PKG_CONFIG_EXECUTABLE ${TOOLCHAIN_PREFIX}-pkg-config)

# path to the target environment
SET(CMAKE_FIND_ROOT_PATH /usr/${TOOLCHAIN_PREFIX}/sys-root/mingw)

# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)

[derselbst]

Ok nice. The toolchain files look good. But we need to find a place to store them and have to think about suitable naming conventions for these files. Let's discuss that on the mailing list first.

Why do you introduce those alloca defines? glib takes care of that kind of abstraction via g_newa.

[carlo-bramini]

The detection of alloca()/_alloca() intrinsic is one fix that I made into my branch for compiling FluidSynth without glib and I included it here in this first step for evaluation. Actually, it has effect on old C89 or C90 compilers like MSVC6, newer versions probably won't need that. I was also thinking what you would think about letting cmake detect this and other stuff, for example I changed things like this:

#if defined(WIN32) && !defined(MINGW32)
    #define FLUID_STRCASECMP         _stricmp
#else
    #define FLUID_STRCASECMP         strcasecmp
#endif

into this:

#if HAVE_STRCASECMP
  #define FLUID_STRCASECMP              strcasecmp
#elif HAVE__STRICMP
  #define FLUID_STRCASECMP              _stricmp
#else
  /* Use GLIB equivalent? */
  #error strcasecmp() is unsupported!
#endif

What do you think?

[derselbst]

glib is an inherent dependency in order to get rid of exactly those kind of abstractions. And it'll also stay a dependency for quite some time as mawe42 now uses gmodule in the ladspa branch. I dont want to replicate the functionality provided by glib, we can never do this as well as glib has done it, it's simply not our field of competence. Thus consequently I should also say: #define FLUID_STRCASECMP g_ascii_strncasecmp ...I would not go that far for now. But I also dont want to introduce more cmake abstraction just to possibly get rid of glib. So in case of alloca I would just say: either use a compiler that supports C99 VLA's OR go with glib.

[mawe42]

The problem with _strincmp has already been fixed in the ladspa branch. It's a typo and should have been _strnicmp.

[derselbst]

The problem with _strincmp has already been fixed in the ladspa branch.

Ok, but this was actually a more general discussion about whether we need more #define abstraction with cmake.

[mawe42]

Ok, but this was actually a more general discussion about whether we need more #define abstraction with cmake.

I understand, it was more directed at carlos anyway, because he used this as an example.