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

[Michael Wild]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100917/3762f176/attachment.pgp>