CMake generates #defines of the form CMAKE_SOMETHING_OR_OTHER. The
commands which produce these appear in .\CMakeFiles\CMakeCCompiler.cmake
and etc. Looking in the *.c and *.h files, I find no sources with any
CMAKE_* defined. I do see many instances in .sln and .proj files, but I
am not clear on how they're getting used. So, it's clear that no
CMAKE_* specific #defines are being taken advantage of in the C source
files. I don't know the source pool well enough to know how necessary
or unnecessary that is.
As for _MSC_VER, I'm not sure what's going on with that, as it's a
Microsoft #define. My VS7.1 IDE is reporting it as undefined when I try
to click for its definition. Maybe the IDE isn't very bright. I'll
look into this later.
Cheers,
Brandon Van Every
Patrick Brannan wrote:
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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > 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
[email protected] <mailto:[email protected]>
http://lists.nongnu.org/mailman/listinfo/chicken-users
_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users
