Object file names use absolute path to sources outside source tree

Is it possible to override the current directory that CMake is using for relative file paths from a specific CMakeLists.txt file? The use case for this is to reduce very long object filenames in windows caused by full paths being used. The specific project has it’s main CMake files in /<folder_a> and a part of that has a chained CMakeLists.txt file inside of /<folder_a> which compiles files inside of /<folder_b>, which is where the long full paths come in. It is not possible to move the CMakeLists.txt file from folder_a to folder_b therefore is it possible in the CMakeLists.txt file to make CMake think that the file is being included from /<folder_b> so that if a source is added, it is added relative to the /<folder_b> path and not the /<folder_a> path?
I’ve tried manually setting CMAKE_CURRENT_SOURCE_DIR and CMAKE_SOURCE_DIR but this does not seem to fool CMake and it continues to use relative paths from <folder_a>

You can give an explicit binary directory in add_subdirectory. For example:

add_subdirectory(folderb "${CMAKE_BINARY_DIR}/folderb")

which should shorten paths for you.

Still seems to produce long paths, given this CMakeLists.txt file:

add_subdirectory(nrfx "${CMAKE_BINARY_DIR}/nrfx")

Which then has the CMakeLists.txt file using absolute paths to the files in a different root directory, however the object files are still using long paths with the full source file path in the output name:


Are you compiling sources that live outside of the source or binary directories?

@brad.king IIRC, there was some recent stuff about using absolute paths in places, but I thought that was Ninja generator-related.

Yes, so <root>/<folder_a> has the cmake files in and is building files in <root>/<folder_b>, there are no cmake files in <folder_b>. Ninja is being used for this specific test but the same paths are present if make is used instead

CMakeLists.txt file inside of <root>/<folder_a> which compiles files inside of <root>/<folder_b>, which is where the long full paths come in.

That is by design, and there is no way to avoid it without putting a CMakeLists.txt file in <root> or above.

For a given source file, CMake choose an object file name that is unique, deterministic, and independent of what other sources may produce object files too. In order to avoid name collisions, that means some part of the path to the source file needs to be used in the path to the object file. When the source files are located inside the source tree, the leading absolute path to the source tree can be left out, and short object names used. When the sources are located outside the source tree, the only way to reference each one uniquely is to use an absolute path.

As for windows path length limitations, we have code to convert the path fragment into a hash when the total path length will be too long. See the code here. Maybe something is going wrong with that heuristic in your case.

Thank you, I will relay that information and see if there’s any more reported issues.