[CMake] CMake 2.8.1 RC 4 is ready to try

[David Cole]

On Tue, Jun 29, 2010 at 5:11 PM, Alexander Neundorf <a.neundorf-work at gmx.net
> wrote:

> On Friday 05 March 2010, Eric Noulard wrote:
> > 2010/3/5 Bill Hoffman <bill.hoffman at kitware.com>:
> > > Eric Noulard wrote:
> > >> 2010/3/5 Bill Hoffman <bill.hoffman at kitware.com>:
> > >>> CMake 2.8.1 RC 4 is ready to try:
> > >>>
> > >>> http://www.cmake.org/files/v2.8/?C=M;O=D
> > >>>
> > >>> Please try your projects with it.   If you find any issues, let me
> > >>> know. I think this is about it.  So, if I don't hear anything by
> > >>> Monday, this is
> > >>> going to be 2.8.1.
> > >>
> > >> Not really a show-stopper since I have no problem using this RC
> > >> but I do have a problem "Building it" on 2 linux boxes
> > >> (first is Ubuntu 9.10 and the other is Fedora 11) using gcc 4.4.1:
> > >>
> > >> Same error:
> > >> Linking CXX executable cmsysTestsCxx
> > >> [ 10%] Built target cmsysTestsCxx
> > >> [ 13%] Built target cmzlib
> > >> [ 14%] Building C object
> Utilities/cmcurl/CMakeFiles/cmcurl.dir/base64.o
> > >> In file included from /usr/include/stdlib.h:320,
> > >>                 from
> > >> /home/usdtim/Erk/CMake/CMake-gitted/Utilities/cmcurl/base64.c:37:
> > >> /usr/include/sys/types.h:110: error: conflicting types for ‘ssize_t’
> > >>
> /home/usdtim/Erk/CMake/CMake-gitted/build/Utilities/cmcurl/config.h:727:
> > >> note: previous declaration of ‘ssize_t’ was here
> > >> make[2]: *** [Utilities/cmcurl/CMakeFiles/cmcurl.dir/base64.o] Erreur
> 1
> > >> make[1]: *** [Utilities/cmcurl/CMakeFiles/cmcurl.dir/all] Erreur 2
> > >> make: *** [all] Erreur 2
> > >>
> > >>
> > >> If I comment-out the offending (re)define in cmcurl/config.h.in
> > >> I can compile and use with no noticeable trouble.
> > >
> > > How are you building it?
> >
> > Yes I do.
> >
> > > Do other versions of CMake have this issue? Sounds
> > > like a try-compile test failed.
> >
> > HEAD has the same issue.
> > I did not tried previous version [yet]
> >
> > the culprit seems to be that
> > generated (configured)
> >
> > Utilities/cmcurl/config.h
> >
> > does the following:
> > #ifndef SIZEOF_SSIZE_T
> > # if SIZEOF_LONG == SIZEOF_SIZE_T
> >    typedef long ssize_t;
> > # elif SIZEOF_LONG_LONG == SIZEOF_SIZE_T
> >    typedef long long ssize_t;
> > # elif SIZEOF___INT64 == SIZEOF_SIZE_T
> >    typedef __int64 ssize_t;
> > # else
> >    typedef int ssize_t;
> > # endif
> >
> > however, in this case CheckTypeSize macro obviously fails to find the
> > size of the type "ssize_t":
> >
> > /* The size of `size_t', as computed by sizeof. */
> > #define SIZEOF_SIZE_T 4
> >
> > /* The size of `ssize_t', as computed by sizeof. */
> >
> >
> > /* The size of `time_t', as computed by sizeof. */
> > #define SIZEOF_TIME_T 4
> >
> > However <sys/types.h> is defining the type...
> >
> > I'll give 2.8.0 and 2.6.4 a compile try and give you feedback.
>
> I think I just had the same issue on an OpenSUSE 11.2 box, and I think I
> committed/pushed a fix to "next":
> http://cmake.org/gitweb?p=cmake.git;a=log;h=refs/heads/next
>
> (is this actually the right thing to do ?)
>
>
Fixing a bug is usually the right thing to do. :-)

And pushing to 'next' is the right way to get your bug fix tested on the
dashboards. (The Continuous dashboards track 'next' and so do the Nightly
and Nightly Expected dashboards. The Nightly 2.8 Release dashboards track
'master'.)

Bill, Brad and I consider merging changes from 'next' to 'master' every
Tuesday now. So... as long as your commits that you push to 'next' look
reasonable to us, then we will merge them next time we meet. And if not,
we'll probably send an email asking a question or two.

I'm pretty sure we'll accept this one. :-)


Cheers,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100629/794b9837/attachment.htm>