On Fri, Sep 17, 2010 at 4:12 AM, Michael Wild <them...@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
_______________________________________________ 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