# No rule to make target

**URL:** https://discourse.cmake.org/t/no-rule-to-make-target/4169
**Category:** Code
**Created:** [September 29, 2021, 4:24pm UTC](https://discourse.cmake.org/t/no-rule-to-make-target/4169 "2021-09-29T16:24:43Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![hex](https://discourse.cmake.org/user_avatar/discourse.cmake.org/hex/32/363_2.png) [@hex](https://discourse.cmake.org/u/hex)
#### Post date: [September 29, 2021, 4:24pm UTC](https://discourse.cmake.org/t/no-rule-to-make-target/4169/1 "2021-09-29T16:24:43Z")

</div>

I am attempting to set dependencies with generator expression, but it is not correctly expanded.

```cmake
add_custom_target(test1 ALL
  DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/foobar
  SOURCES foo.bar
)

add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foobar
  COMMAND echo dummyfoobargenerator
  DEPENDS $<TARGET_PROPERTY:test1,SOURCES>
)

```

this results in error:

```auto
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/build
gmake[2]: *** No rule to make target 'foobar.rule', needed by 'foobar'. Stop.
gmake[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/test1.dir/all] Error 2
gmake: *** [Makefile:101: all] Error 2

```

This is a bit unexpected. foobar is not part of target properties sources, it was not my intention to use it as such. Do i have to filter them out or is there a better way?

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 29, 2021, 5:58pm UTC](https://discourse.cmake.org/t/no-rule-to-make-target/4169/2 "2021-09-29T17:58:09Z")

</div>

I suspect that the current directory is not well-defined and that’s why this isn’t happy in the end. I think that the `Makefiles` generators add some “sources” for their internal bookkeeping (such as the `.rule` files). Filtering could help, but I suspect that the genex doesn’t work well for out-of-source builds since the paths don’t seem to be normalized at all. Does it work with the `Ninja` generator?

@brad.king?

---

<div class="post-metadata">

### Author: ![hex](https://discourse.cmake.org/user_avatar/discourse.cmake.org/hex/32/363_2.png) [@hex](https://discourse.cmake.org/u/hex)
#### Post date: [September 29, 2021, 9:21pm UTC](https://discourse.cmake.org/t/no-rule-to-make-target/4169/3 "2021-09-29T21:21:59Z")

</div>

using Ninja results in cyclic dependency error. I used relative paths for conciseness. The behaviour is the same with absolute paths.

Normalizing paths with genex is a challenge, though. I tried other things but always hit the rule not found error.

here is a simplified version of the problem:

```cmake
cmake_minimum_required(VERSION 3.20)

project(MyProj LANGUAGES NONE)

add_custom_target(test1 ALL
	COMMAND ${CMAKE_COMMAND} -E echo "this line:$<TARGET_PROPERTY:test1,SOURCES>"
	SOURCES foo.bar
	COMMAND_EXPAND_LISTS
)

```

```auto
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/build
this line:foo.bar /tmp/test/build/CMakeFiles/test1 /tmp/test/build/CMakeFiles/test1.rule
Built target test1
[Finished in 0.1s]

```

this version builds successfully.  
it makes me think that CMake might have created a target-level dependency for target\_property, even so this should only happen for `TARGET_xxx_FILE`, etc.

these restrictions might to also apply to `add_custom_command`.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [October 1, 2021, 11:34am UTC](https://discourse.cmake.org/t/no-rule-to-make-target/4169/4 "2021-10-01T11:34:39Z")

</div>

Thanks, that looks like a small enough example for tracking down the cause at least. Could you please file it as [an issue](https://gitlab.kitware.com/cmake/cmake/-/issues)? I’m not sure that the solution is trivial however. Thanks.

---

<div class="post-metadata">

### Author: ![hex](https://discourse.cmake.org/user_avatar/discourse.cmake.org/hex/32/363_2.png) [@hex](https://discourse.cmake.org/u/hex)
#### Post date: [October 3, 2021, 1:25pm UTC](https://discourse.cmake.org/t/no-rule-to-make-target/4169/5 "2021-10-03T13:25:49Z")

</div>

another thing i observed is that the output for `get_target_property(mysrcs test1 SOURCES)` is different from `$<TARGET_PROPERTY:test1,SOURCES>`: the former does not show the internal files. Are target\_properties always read before generator expressions? Should i mention this in the same gitlab issue?

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [October 3, 2021, 4:07pm UTC](https://discourse.cmake.org/t/no-rule-to-make-target/4169/6 "2021-10-03T16:07:21Z")

</div>

`get_target_property` works at configure time, so it may have out-of-date information (e.g., if a `target_sources` is performed after the initial query). The generator seems to add additional sources before the generator expression is evaluated.

---

<div class="post-metadata">

### Author: ![dbear496](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/d/8baadc/32.png) [@dbear496](https://discourse.cmake.org/u/dbear496)
#### Post date: [October 4, 2026, 2:32pm UTC](https://discourse.cmake.org/t/no-rule-to-make-target/4169/7 "2026-10-04T14:32:16Z")

</div>

I’m running into the same problem, but I can’t find any open issue for this on the kitware gitlab. Was an issue ever created for this?

edit: found it [here](https://gitlab.kitware.com/cmake/cmake/-/work_items/22718)