Windows zconf_nextfiles fails to find wildcard matches.

[nashif]

Reported by Joakim Andersson:

The windows version of zconf_nextfiles will not be able to match wildcard searchen in $srctree if parts of the wildcard search can be matched in the current directory the tools is running. An example of this is $srctree=$ZEPHYR_BASE conf --olddefconfig Kconfig, if the current directory contains a folder arch then arch//soc//Kconfig.defconfig will not be found.

The reason is that win_process_directories finds arch/ and then processes the rest of the match, and will then not try $srctree/arch/

{code:java} // win_process_directories(directories_path="arch/", remain_path="soc/Kconfig.defconfig" hFind = FindFirstFile(fullname, &FindFileData); if (hFind == INVALID_HANDLE_VALUE) { env = getenv(SRCTREE); if (env) { sprintf(path, "%s/%s", env, fullname); strcpy(fullname, path); } hFind = FindFirstFile(fullname, &FindFileData); }

(Imported from Jira ZEP-1963)

[nashif]

by Leandro Pereira:

I have some code here which I don't know how to test yet (still have to set up a Windows development machine). If someone is willing to test a patch that might not work, I can publish it to Gerrit. The patch implements just enough of glob() and globfree() for Windows, so that zconf_nextfiles() can be the same function both on Linux and on Windows, which might fix this problem.

[nashif]

by Joakim Andersson:

I can test it. I have the environment set up.

[nashif]

by Leandro Pereira:

Joakim Andersson , could you please take a look? Without the environment I couldn't test to see if this even compiles, so you might need to poke around. In any case, I'll set up my Windows machine to build this once I have some time this week.

[nashif]

by Joakim Andersson:

I poked around a bit, but there is still a way to go. It's best you set up your windows machine to test yourself.

To reproduce the issue: have a .config file: CONFIG_SERIAL=n CONFIG_UART_NRF5=y CONFIG_SOC_FAMILY_NRF5=y CONFIG_BOARD_NRF52_PCA10040=y CONFIG_MDEF=n CONFIG_GPIO=y CONFIG_ARM=y CONFIG_UART_CONSOLE=y CONFIG_SOC_SERIES_NRF52X=y CONFIG_GPIO_AS_PINRESET=y CONFIG_CONSOLE=y CONFIG_BLUETOOTH=y CONFIG_BLUETOOTH_CONTROLLER=y CONFIG_SOC_NRF52832=y

Run srctree=$ZEPHYR_BASE kconfig/conf.exe --olddefconfig Kconfig from the directory where .config is placed. To see if the issue has been fixed: mkdir arch srctree=$ZEPHYR_BASE kconfig/conf.exe --olddefconfig Kconfig

[nashif]

by Joakim Andersson:

To setup the windows enviroment use this: doc/getting_started/installation_win.rst, recently merged to master.

[nashif]

by Leandro Pereira:

OK, so I set up the environment like the documentation says. It worked well, and I got an ARM hello world binary.

However, I couldn't reproduce the problem being described using code straight out from the repository.

I've substituted the .config file generated inside outdir/nrf52_pca10040 with the one provided, and executed the command (changing kconfig/conf.exe to scripts/kconfig/conf.exe). The .config file seems to be created as usual.

The arch directory already exists inside that directory.

What should I actually be looking for here?

[nashif]

by Joakim Andersson:

Hey I had some differences in the enviroment because I got the issue during the CMake prototype work. I have now managed to reproduce this with the msys/windows enviroment.

1. Setup with doc/getting_started/installation_win.rst

2. Open up MSYS2 MinGW 64-bit shell (if we use MSYS2 MSYS shell it does not use the windows specific code).

3. cd samples/bluetooth/beacon

4. make BOARD=nrf52_pca10040 You should now see output like this: {code:java} Error processing 'C:/Users/joan/repos/zephyr//C:\Users\joan\repos\zephyr\samples\hello_world\outdir\nrf52_pca10040\arch\common\soc/*' #123 #

   configuration written to .config

   # Error processing 'C:/Users/joan/repos/zephyr//C:\Users\joan\repos\zephyr\samples\hello_world\outdir\nrf52_pca10040\arch\common\soc/*' #123.

5. cd outdir/nrf52_pca10040

6. Replace .config with what I pasted earlier (result of merge_config.sh).

7. srctree=$ZEPHYR_BASE scripts/kconfig/conf.exe --olddefconfig Kconfig Results in ouput {code:java} Error processing 'C:/Users/joan/repos/zephyr//C:\Users\joan\repos\zephyr\samples\hello_world\outdir\nrf52_pca10040\arch\common\soc/*' #123. #

   configuration written to .config

   # C:\Users\joan\repos\zephyr\Kconfig.zephyr:9:warning: environment variable KERNELVERSION undefined C:\Users\joan\repos\zephyr\boards\Kconfig:10:warning: config symbol defined without type

8. srctree=$ZEPHYR_BASE scripts/kconfig/conf.exe --silentoldconfig Kconfig The config is now completely messed up and will restart.. {code:java} Error processing 'C:/Users/joan/repos/zephyr//C:\Users\joan\repos\zephyr\samples\hello_world\outdir\nrf52_pca10040\arch\common\soc/' #123

   • Restart config...
   • General Kernel Options

   • Uses Device Tree (HAS_DTS) [N/y/?] n Multi-threading (MULTITHREADING) [Y/n/?] y Number of coop priorities (NUM_COOP_PRIORITIES) [16] 16 Number of preemptible priorities (NUM_PREEMPT_PRIORITIES) [15] 15 Priority of initialization/main thread (MAIN_THREAD_PRIORITY) [0] 0 Priority inheritance ceiling (PRIORITY_CEILING) [0] 0 Size of stack for initialization and main thread (MAIN_STACK_SIZE) [1024] 1024 Size of stack for idle thread (IDLE_STACK_SIZE) [256] 256 ISR and initialization stack size (in bytes) (ISR_STACK_SIZE) [2048] 2048 Thread custom data (THREAD_CUSTOM_DATA) [N/y/?] n Number of timers available for dynamic allocation (NUM_DYNAMIC_TIMERS) [0] 0 Enable errno supportC:\Users\joan\repos\zephyr\boards\Kconfig:10:warning: config symbol defined without type .config:82:warning: symbol value '' invalid for SYS_CLOCK_HW_CYCLES_PER_SEC (ERRNO) [Y/n/?] y System tick frequency (in ticks/second) (SYS_CLOCK_TICKS_PER_SEC) [100] 100 System clock's h/w timer frequency (SYS_CLOCK_HW_CYCLES_PER_SEC) [] (NEW) aborted!

Console input/output is redirected. Run 'make oldconfig' to update configuration.

[nashif]

by Leandro Pereira:

I'll take another look tomorrow, Joakim Andersson .

[nashif]

by Andrew Boie:

Joakim Andersson Can I ask why you are setting private build system variables and running Kconfig directly? Why not 'make oldconfig' or 'make silentoldconfig'? Is this not reproducible with the build system targets? I suppose in other words: what's the broader context for this issue?

[nashif]

by Sebastian Bøe:

I am Joakim's colleague and can answer on his behalf.

bq. Can I ask why you are setting private build system variables and running Kconfig directly? Why not 'make oldconfig' or 'make silentoldconfig'?

This is because the bug was discovered when working on the CMake-port. The CMake-port does not yet have any other interface to Kconfig than Kconfig itself.

bq. Is this not reproducible with the build system targets? I suppose in other words: what's the broader context for this issue?

I was not able to reproduce this with Kbuild/Make. In addition, the CMake-port is able to work around this limitation. The broader context is then that there exists a bug in an internal tool of the build system. This bug could be ignored and worked around without significant consequences AFAICT.