I am noticing that throughout the source pool, there are #defines meant
for the autoconf toolchain, like
HAVE_CONFIG_H
_MSC_VER
C_WINDOWS_DLL
and so forth and so on. When I do 'cmake -G "Visual Studio .Net 2003"'
I get .sln files, but they don't have these symbols #defined. There's
no reason they would: cmake is not a drop-in replacement for autoconf.
It merely performs the same task more portably, in its own way.
Consequently, there is significant work to be done to ensure cmake is
setting appropriate #defines before declaring that the new tarball
supports cmake. The work as it stands would probably be best described
as pre-alpha quality.
The cmake builds have yet to work for me, and I do have healthy MinGW,
retail VS7.1, VCToolkit, and Cygwin environments. If they have ever
worked for anybody, it's probably because they ran ./configure first,
then cmake, and thereby got the needed #defines. That pretty much
defeats the purpose of cmake. I'm happy to go up the learning curve of
what needs to be done to put things right, but I wanted to clarify where
things are actually at now. We've seen that cmake is easy to get
started with, but we have more of a learning curve to go up.
Cheers,
Brandon Van Every
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users
