Fix CMake configure error: move add_dependencies after target definitions

[Copilot]

add_dependencies(wpsnative ... pixiewps_exec wpa_supplicant_exec) referenced targets before their add_custom_target() declarations, causing a CMake configure-time failure. This broke builds in CI environments (including masking the dummy flex/bison workaround).

• Moved add_dependencies(wpsnative ...) to after both pixiewps_exec and wpa_supplicant_exec target definitions at the end of the file

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

[fulvius31]

@copilot I just need to know if this issue caused the build to fail in hosts that did not have bison and flex installed

[Copilot]

@copilot I just need to know if this issue caused the build to fail in hosts that did not have bison and flex installed

Yes — this add_dependencies ordering bug caused CMake configuration to fail entirely (fatal error: The dependency target "pixiewps_exec" of target "wpsnative" does not exist). Since CMake aborted at configure time, the build never started, so the libnl ExternalProject step (which is what actually needs flex/bison) was never reached.

The dummy flex/bison scripts on lines 44-51 already handle the libnl requirement, but you couldn't tell because CMake configuration was dying first. With this fix (commit 60facc1), CMake configure should succeed and the dummy scripts should handle the flex/bison dependency without needing them installed on the host.

[fulvius31]

@copilot I just need to know if this issue caused the build to fail in hosts that did not have bison and flex installed

Yes — this add_dependencies ordering bug caused CMake configuration to fail entirely (fatal error: The dependency target "pixiewps_exec" of target "wpsnative" does not exist). Since CMake aborted at configure time, the build never started, so the libnl ExternalProject step (which is what actually needs flex/bison) was never reached.

The dummy flex/bison scripts on lines 44-51 already handle the libnl requirement, but you couldn't tell because CMake configuration was dying first. With this fix (commit 60facc1), CMake configure should succeed and the dummy scripts should handle the flex/bison dependency without needing them installed on the host.

@copilot So, with this fix we can remove all these .c and .h that I imported to make it work in a host that did not have bison and flex installed?

I'm referring to :

[ematch_grammar.h]
[ematch_syntax.c]
[ematch_syntax.h]
[pktloc_grammar.c]
[pktloc_grammar.h]
[pktloc_syntax.c]
[pktloc_syntax.h]

[Copilot]

@copilot I just need to know if this issue caused the build to fail in hosts that did not have bison and flex installed

Yes — this add_dependencies ordering bug caused C...

No, those files should stay. Here's why:

The dummy flex/bison scripts only do exit 0 — they produce no output files. They exist solely to pass libnl's configure-time check (configure verifies flex/bison exist, and the dummies satisfy that).

However, during make, if the build system detects that the .y/.l source files have timestamps newer than (or equal to) the generated .c/.h files, it will try to re-invoke flex/bison. The dummy scripts would run, produce nothing, and the build would fail.

Your PATCH_COMMAND (lines 140-149) copies these pre-generated files with fresh timestamps into the libnl source tree, ensuring they're newer than the .y/.l sources. This prevents make from trying to regenerate them.

So the two mechanisms work together:

• Dummy scripts → satisfy configure-time tool check
• Pre-generated files + PATCH_COMMAND → prevent build-time regeneration via fresh timestamps

[fulvius31]

@copilot I just need to know if this issue caused the build to fail in hosts that did not have bison and flex installed

Yes — this add_dependencies ordering bug caused C...

No, those files should stay. Here's why:

The dummy flex/bison scripts only do exit 0 — they produce no output files. They exist solely to pass libnl's configure-time check (configure verifies flex/bison exist, and the dummies satisfy that).

However, during make, if the build system detects that the .y/.l source files have timestamps newer than (or equal to) the generated .c/.h files, it will try to re-invoke flex/bison. The dummy scripts would run, produce nothing, and the build would fail.

Your PATCH_COMMAND (lines 140-149) copies these pre-generated files with fresh timestamps into the libnl source tree, ensuring they're newer than the .y/.l sources. This prevents make from trying to regenerate them.

So the two mechanisms work together:

• Dummy scripts → satisfy configure-time tool check
• Pre-generated files + PATCH_COMMAND → prevent build-time regeneration via fresh timestamps

@copilot How can I get rid of those .c and .h files ?

[Copilot]

@copilot I just need to know if this issue caused the build to fail in hosts that did not have bison and flex installed

...

Done in f830a77. Replaced the PATCH_COMMAND copy with cmake -E touch on the tarball's own pre-generated files (the libnl 3.2.25 release tarball already ships them — they just need fresh timestamps to prevent make from trying to regenerate). Deleted all 8 files and the libnl-generated/ directory.

[fulvius31]

@copilot the build now is failing

[Copilot]

@copilot the build now is failing

Fixed in fee7995 — reverted the file removal. The touch approach was wrong because I assumed the libnl tarball ships pre-generated files, but it doesn't — the tarball only contains .l and .y source files, no generated .c/.h output.

Those 8 files cannot be removed without requiring flex/bison on the build host. If you want to eliminate them, the cleanest option is to install flex and bison in your CI environment (apt-get install flex bison) and remove the dummy scripts, pre-generated files, and PATCH_COMMAND entirely.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/thom311/libnl/contents/lib/route/Makefile.am
  • Triggering command: /usr/bin/curl curl -s REDACTED (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)