Notes
(0028272) Eric NOULARD (developer) 2012-01-12 02:07	In this particular case the name clash is complete so may be it's "normal" behavior. Moreover having same name in build tree and source tree (for matching source/build hierarchy) for a source file prevent you for building in source and even if it is always better as long as CMake does not suppport mandatory out-of-source build you may get unexpected bug report if anyone build your project in-source. In the end you may really be looking for trouble if there are two associated (but different) ${CMAKE_CURRENT_SOURCE_DIR}/a.h ${CMAKE_CURRENT_BINARY_DIR}/a.h header files? How would you tell CMake which one should be included by other ${CMAKE_CURRENT_SOURCE_DIR}/.cpp ${CMAKE_CURRENT_BINARY_DIR}/.cpp You'd really better off putting your generated file in some distinct dir like: ${CMAKE_CURRENT_BINARY_DIR}/bison/* since you are generating those it's not a big deal. That said CMake should certainly throw an error in your particular use case.

(0028277) freddie (reporter) 2012-01-12 08:05	I was not looking for workarounds or explanations that extreme cases exist when it might be a bad idea. I am simply stating that in my non-singular use case, despite assurances that object file names are unique, cmake doesn't actually make them unique. And I don't see why it should give me an error, too, since had it used a unique name, everything would have worked the way I want. Out of courtesy, let me address the suggestions, though: 1. problem of in-source build: imagine that I ensure the location of my generated files is different from source by comparing CMAKE_BINARY_DIR to CMAKE_SOURCE_DIR; in the case when they are the same I might create a parallel structure for generated files, but when they are different I don't wish to as it already exists; 2. problem of clashing header names: I might be putting generated headers in some central location, or I might be using a parallel hierarchy for headers only (which I might later package into a tarball for distributing) which can be accessed distinctly, or I might not have clashing header names at all. 3. Putting stuff into CMAKE_CURRENT_BINARY_DIR/bison is not a solution since in my source tree I might have a bison/ subdirectory.

(0028278) Eric NOULARD (developer) 2012-01-12 08:25	Hi Freddie, Sorry if my previous comment seems a bit harsh. It only express my opinion which: A) your use case seems seldom used to me B) one cannot safely forbid in-source build: http://public.kitware.com/Bug/view.php?id=6672 [^] thus if you "create a parallel structure for generated files" then you can ALWAYS do this. C) If the use case is not supported CMake should error-out and not just emit some possibly cryptic "warnings". So I fully respect your opinion and needs, I did just expressed mine. May be others, including official CMake developers, will have a different opinion, so may be they will find time to fix CMake for this use case.

(0028279) Brad King (manager) 2012-01-12 10:03	The goals of CMake's object file naming are: (1) Name is deterministic from the path to the source file and the target compiling it (2) Name does not depend on analysis of multiple source files (implied by 1) (3) Name works for both in-source and out-of-source builds Due to (3) we never considered an identically located and named source file in the source and build trees. Clearly this is not a supported use case in current CMake. Some work will be needed to add support for this, and it will necessarily change the location of object files in existing projects due to goal (2). What names do you propose for the two object files?

(0028282) freddie (reporter) 2012-01-12 17:28	I would add another requirement, that the naming be bijective (that is, the object file is uniquely determined from the source file, and vice versa), given CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR. As to the naming suggestions, I would map as follows: TOPSRC = CMAKE_SOURCE_DIR CURSRC = CMAKE_CURRENT_SOURCE_DIR TOPBIN = CMAKE_BINARY_DIR CURBIN = CMAKE_CURRENT_BINARY_DIR OUT = CURBIN/CMakeFiles/<tgt>.dir/obj * CURSRC/subdir/a.cpp -> OUT.src/subdir/a.cpp.o * TOPSRC/subdir/a.cpp -> OUT.tsrc/subdir/a.cpp.o * CURBIN/subdir/a.cpp -> OUT.bin/subdir/a.cpp.o * TOPBIN/subdir/a.cpp -> OUT.tbin/subdir/a.cpp.o * /absdir/a.cpp -> OUT.abs/absdir/a.cpp.o [here, "subdir/" and "absdir/" could be empty] Only the last one is required; the first one is useful for backwards compatibility, and the ones in between are optional but make for shorter pathnames. All output directories are named differently. I think that currently CURSRC/a.cpp and /a.cpp (and CURBIN/a.cpp, as mentioned) would all map to the same name, which this approach aims to address.

(0041964) Kitware Robot (administrator) 2016-06-10 14:28	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2012-01-11 19:12	freddie	New Issue
2012-01-12 02:07	Eric NOULARD	Note Added: 0028272
2012-01-12 08:05	freddie	Note Added: 0028277
2012-01-12 08:25	Eric NOULARD	Note Added: 0028278
2012-01-12 10:03	Brad King	Note Added: 0028279
2012-01-12 10:03	Brad King	Status	new => backlog
2012-01-12 17:28	freddie	Note Added: 0028282
2016-06-10 14:28	Kitware Robot	Note Added: 0041964
2016-06-10 14:28	Kitware Robot	Status	backlog => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:28	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships