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