[CMake] Simclist library produces simclist.c.o, simclist.c.i, simclist.c.s ...

[David Cole]

On Fri, Sep 17, 2010 at 4:12 AM, Michael Wild <themiwi at gmail.com> wrote:

> On 17. Sep, 2010, at 9:41 , SC wrote:
>
> > Hi there,
> >
> > I recently upgraded my dev system from Ubuntu 8.04 to Ubuntu 10.4. This
> made me change from Cmake 2.4-patch7 to
> > Cmake 2.8.0.
> >
> > Since then, generating a makefile with "Cmake ." in the Simclist library
> source directory produces the following :
> >
> >
> #=============================================================================
> > # Target rules for targets named simclist
> >
> > # Build rule for target.
> > simclist: cmake_check_build_system
> > $(MAKE) -f CMakeFiles/Makefile2 simclist
> > .PHONY : simclist
> >
> > # fast build rule for target.
> > simclist/fast:
> > $(MAKE) -f CMakeFiles/simclist.dir/build.make
> CMakeFiles/simclist.dir/build
> > .PHONY : simclist/fast
> >
> > simclist.o: simclist.c.o
> > .PHONY : simclist.o
> >
> > # target to build an object file
> > simclist.c.o:
> > $(MAKE) -f CMakeFiles/simclist.dir/build.make
> CMakeFiles/simclist.dir/simclist.c.o
> > .PHONY : simclist.c.o
> >
> > simclist.i: simclist.c.i
> > .PHONY : simclist.i
> >
> > # target to preprocess a source file
> > simclist.c.i:
> > $(MAKE) -f CMakeFiles/simclist.dir/build.make
> CMakeFiles/simclist.dir/simclist.c.i
> > .PHONY : simclist.c.i
> >
> > simclist.s: simclist.c.s
> > .PHONY : simclist.s
> >
> > # target to generate assembly for a file
> > simclist.c.s:
> > $(MAKE) -f CMakeFiles/simclist.dir/build.make
> CMakeFiles/simclist.dir/simclist.c.s
> > .PHONY : simclist.c.s
> >
> >
> > As you can see, the ".c" extension is added to output files. As a
> consequence, I generate simclist.c.o where I
> > expect simclist.o. I quickly browsed the ChangeLogs of 2.8 and the FAQ
> but cound find any tip on this.
> >
> > Is this a known bug or an incompatibility issue, or maybe an issue in the
> simclist ?
> >
> > The simclist Cmakelists.txt file is as follows :
> >
> > cmake_minimum_required(VERSION 2.6)
> > PROJECT(simclist)
> >
> > # simclist options
> > OPTION(SIMCLIST_DEBUG
> > "Build with debug code and debug symbols enabled"
> > OFF)
> > OPTION(SIMCLIST_THREADING
> > "Build with simclist threading enable"
> > OFF)
> > OPTION(SIMCLIST_NO_DUMPRESTORE
> > "Disable building of dump & restore functionalities"
> > OFF)
> > OPTION(SIMCLIST_ALLOW_LOCATIONBASED_HASHES
> > "Allow list_hash() to work exclusively on memory locations"
> > OFF)
> >
> > # expand selected options
> > SET(SIMCCFLAGS "")
> > # build with debug?
> > IF(SIMCLIST_DEBUG)
> > SET(SIMCCFLAGS "${SIMCCFLAGS} -DSIMCLIST_DEBUG")
> > ENDIF(SIMCLIST_DEBUG)
> > # build with threading?
> > IF(SIMCLIST_THREADING)
> > SET(SIMCCFLAGS "${SIMCCFLAGS} -DSIMCLIST_WITH_THREADS")
> > ENDIF(SIMCLIST_THREADING)
> > # build without dump/restore functionalities?
> > IF(SIMCLIST_NO_DUMPRESTORE)
> > SET(SIMCCFLAGS "${SIMCCFLAGS} -DSIMCLIST_NO_DUMPRESTORE")
> > ENDIF(SIMCLIST_NO_DUMPRESTORE)
> > IF(SIMCLIST_ALLOW_LOCATIONBASED_HASHES)
> > SET(SIMCCFLAGS "${SIMCCFLAGS} -DSIMCLIST_ALLOW_LOCATIONBASED_HASHES")
> > ENDIF(SIMCLIST_ALLOW_LOCATIONBASED_HASHES)
> > SET_SOURCE_FILES_PROPERTIES(simclist.c COMPILE_FLAGS "${SIMCCFLAGS}")
> >
> > # main building stuff
> > ADD_LIBRARY(simclist SHARED simclist.c)
> > SET(CMAKE_C_FLAGS "-O2 -Wall -std=c99")
> >
> > Any idea welcomed !
> >
> > Thank you
> >
>
>
> No, this is intentional, I suspect to avoid conflicts. There are people
> doing stuff like
>
> add_library(foo foo.c foo.cpp foo.f)
>
> Why is this a problem for you?
>
> Michael
>
> --
> There is always a well-known solution to every human problem -- neat,
> plausible, and wrong.
> H. L. Mencken
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>


Michael's exactly right. We consider the name and location of the object
files to be an implementation detail of CMake (and it's different on
different systems with different compilers....) -- you cannot rely on those
details being exactly the same from version to version of CMake. Especially
not versions that are spaced *years* apart from each other.


HTH,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100917/1d78774c/attachment-0001.htm>