chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] cmake doesn't have #defines


From: Brandon J. Van Every
Subject: Re: [Chicken-users] cmake doesn't have #defines
Date: Thu, 03 Nov 2005 13:06:08 -0800
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

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* <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








reply via email to

[Prev in Thread] Current Thread [Next in Thread]