Potential issue with CMAKE_OBJECT_PATH_MAX

[alexsven]

Since nrf5340_cpunet_reset.c is located in the boards folder (zephyr/boards/arm/nrf5340dk_nrf5340), the path for linking it in might quickly be too long, depending on where the project is stored on the local machine.

One easy fix is to make sure to place the project as close to root as possible, but this might not be an option for all users.

[tejlmand]

Just a note: CMAKE_OBJECT_PATH_MAX has to do with the full path, it doesn't help regarding library names that are too long.

When using zephyr_library() without a name, then the lib name is constructed based on it's location:

zephyr/cmake/extensions.cmake

Lines 391 to 409 in 4b54d36

	macro(zephyr_library)
	zephyr_library_get_current_dir_lib_name(${ZEPHYR_BASE} lib_name)
	zephyr_library_named(${lib_name})
	endmacro()
	# Determines what the current directory's lib name would be according to the
	# provided base and writes it to the argument "lib_name"
	macro(zephyr_library_get_current_dir_lib_name base lib_name)
	# Remove the prefix (/home/sebo/zephyr/driver/serial/CMakeLists.txt => driver/serial/CMakeLists.txt)
	file(RELATIVE_PATH name ${base} ${CMAKE_CURRENT_LIST_FILE})
	# Remove the filename (driver/serial/CMakeLists.txt => driver/serial)
	get_filename_component(name ${name} DIRECTORY)
	# Replace / with __ (driver/serial => driver__serial)
	string(REGEX REPLACE "/" "__" name ${name})
	set(${lib_name} ${name})
	endmacro()

So best solution in this case would be to slowly deprecate zephyr_library() and instead use zephyr_library_named() (or even start a transistion towards plain CMake, see #8827 )

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[koffes]

This issue is still valid.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[tejlmand]

still valid, but we cannot change CMake.
What we can do is to raise awareness, for example by printing a warning together with information about using zephyr_library_named() instead if lib name becomes too long.

This is more an enhancement than a bug.
Bugs should be filed for specific libraries or a list of libraries that causes this to happen, else it is hard to know exactly what to fix.

[nordicjm]

I asked on the cmake discussion forum and this should not be an issue, see https://discourse.cmake.org/t/object-file-names-use-absolute-path-to-sources-outside-source-tree/6383/6 and corresponding code at https://gitlab.kitware.com/cmake/cmake/-/blob/v3.24.1/Source/cmLocalGenerator.cxx#L3516-3560 which was last updated 7 months ago so should be in cmake version 3.23 onwards

[mithunpandey]

We are also facing the same issue
we are using twister to run test on out our HW
python zephyr/scripts/twister --device-testing --device-serial COM5 -p nucleo_h743zi -T app-to-build/examples
we are using GitHub, and a self hosted windows runner
And the cmake is getting failed with

CMake Warning in C:/actions-runner/_work/edge-rtos-github-workflows/edge-rtos-github-workflows/zephyr/arch/arm/core/aarch32/cortex_m/CMakeLists.txt:
The object file directory

C:/actions-runner/_work/edge-rtos-github-workflows/edge-rtos-github-workflows/twister-out/nucleo_h743zi/drivers/SPI/Async_SPI/examples.drivers.SPI.Async_SPI/zephyr/arch/arch/arm/core/aarch32/cortex_m/CMakeFiles/arch__arm__core__aarch32__cortex_m.dir/./

has 252 characters. The maximum full path to an object file is 250
characters (see CMAKE_OBJECT_PATH_MAX). Object file

fault.c.obj

cannot be safely placed under this directory. The build may not work
correctly.

[JPHutchins]

This issue is quite prevalent when running twister from Windows.

[PerMac]

We resolved the issue in twister on windows by using --no-detailed-test-id and --short-build-path