Not true, Brandon. I'm not sure what I got wrong but they worked for
me on 2.2 after fixing the tcp imports issue. I never ran configure. I
will try to build again today and see what's going on.
On 11/2/05, *Brandon J. Van Every* <address@hidden
<mailto:address@hidden> > wrote:
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
address@hidden <mailto:address@hidden>
http://lists.nongnu.org/mailman/listinfo/chicken-users