[CMake] Failure to create CMakeFiles/libname.dir

[David Cole]

On Sat, Aug 18, 2012 at 8:27 AM, Michael Wild <themiwi at gmail.com> wrote:

> On 08/18/2012 02:20 PM, David Cole wrote:
> >
> >
> > On Sat, Aug 18, 2012 at 6:57 AM, Michael Wild <themiwi at gmail.com
> > <mailto:themiwi at gmail.com>> wrote:
> >
> >     On 08/17/2012 05:25 PM, David Cole wrote:
> >     >
> >     >
> >     > On Fri, Aug 17, 2012 at 11:16 AM, Rolf Eike Beer <eike at sf-mail.de
> >     <mailto:eike at sf-mail.de>
> >     > <mailto:eike at sf-mail.de <mailto:eike at sf-mail.de>>> wrote:
> >     >
> >     >     Am Freitag, 17. August 2012, 14:17:33 schrieb Michael Wild:
> >     >     > Yes, e.g. i386 works fine:
> >     >     >
> >     >
> >
> https://buildd.debian.org/status/fetch.php?pkg=freefoam&arch=i386&ver=0.1.0%
> >     >     > 2Bdfsg-1&stamp=1345172639
> >     >     >
> >     >     > It seems that only the more exotic (non-Intel) ones have
> >     this issue. I
> >     >     > forgot to mention that mipsel and sparc have the same
> >     problem. Except
> >     >     > for mipsel they are all big-endian...
> >     >
> >     >     You are looking at the totally wrong place I guess ;)
> >     >
> >     >     i386 command:
> >     >
> >     >     cd
> >     >
> >
> /build/buildd-freefoam_0.1.0+dfsg-1-i386-5n1wds/freefoam-0.1.0+dfsg/obj-
> >     >     i486-linux-gnu/src/Pstream/dummy && /usr/bin/g++
> >     >     -DdummyPstream_EXPORTS -DDP
> >     >     -DNoRepository -Dlinux -g -O2 -fstack-protector
> >     >     --param=ssp-buffer-size=4 -
> >     >     Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
> -fpermissive -
> >     >     D_FORTIFY_SOURCE=2 -fPIC -I/build/buildd-freefoam_0.1.0+dfsg-1-
> >     >     i386-5n1wds/freefoam-0.1.0+dfsg/obj-i486-linux-gnu/include
>  -o
> >     >     CMakeFiles/dummyPstream.dir/dummyIPstreamImpl.C.o -c
> >     /build/buildd-
> >     >     freefoam_0.1.0+dfsg-1-
> >     >
> >     i386-5n1wds/freefoam-0.1.0+dfsg/src/Pstream/dummy/dummyIPstreamImpl.C
> >     >
> >     >     powerpc build:
> >     >
> >     >     cd
> >     >
> >
> /build/buildd-freefoam_0.1.0+dfsg-1-powerpc-810bTJ/freefoam-0.1.0+dfsg/obj-
> >     >     powerpc-linux-gnu/src/Pstream/dummy && /usr/bin/g++
> >     >     -DdummyPstream_EXPORTS -
> >     >     DDP -DNoRepository -g -O2 -fstack-protector
> >     >     --param=ssp-buffer-size=4 -Wformat
> >     >     -Werror=format-security -D_FORTIFY_SOURCE=2 -fpermissive
> >     >     -D_FORTIFY_SOURCE=2 -
> >     >     fPIC -I/build/buildd-freefoam_0.1.0+dfsg-1-
> >     >
> powerpc-810bTJ/freefoam-0.1.0+dfsg/obj-powerpc-linux-gnu/include
> >     >      -D -o
> >     >     CMakeFiles/dummyPstream.dir/dummyIPstreamImpl.C.o -c
> >     /build/buildd-
> >     >     freefoam_0.1.0+dfsg-1-
> >     >
> >
> powerpc-810bTJ/freefoam-0.1.0+dfsg/src/Pstream/dummy/dummyIPstreamImpl.C
> >     >
> >     >     The important difference is:
> >     >
> >     >     the PowerPC build has a stray "-D" in it, so g++ takes the
> >     following
> >     >     -o as
> >     >     define and the following object file name as input instead of
> >     as output.
> >     >
> >     >
> >     > NICE EYE!!!!!
> >
> >     How very embarrassing! Thanks for helping me out with this one.
> >
> >
> > Just curious: was it a misspelled variable name? Would you have gotten a
> > warning if you used "--warn-unused-vars" on the cmake command line?
> >
>
> Not misspelled, it was a unhandled situation. When I originally wrote
> that code years ago I consciously decided to only handle i386 and x86_64
> and figured I'd deal with other architectures when the situation crops
> up. Well, I completely forgot about that, and here it is ;-) And yes,
> that flag would have fired, but then I also rely on undefined variables...
>
> Michael
>


:-)

Thanks for the explanation.

Time to deal with some new architectures...

One technique I like to use for stuff like this is to be explicit about it
with a super-helpful error message as early as possible, like we do in the
"git too old" case for ExternalProject:

    if(git_version VERSION_LESS 1.6.5)
      message(FATAL_ERROR "error: git version 1.6.5 or later required for
'git submodule update --recursive': git_version='${git_version}'")
    endif()

I firmly believe (though I have no direct evidence) that using this
technique saves us from some small but distracting number of bug reports,
and actually helps the people who encounter these conditions to solve
problems themselves without any further information.

Glad you got to the bottom of this one. Sometimes it just takes a few extra
sets of eyeballs.


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