1

I'm using this rwildcard make function (taken from https://stackoverflow.com/a/18258352)

ifeq ($(OS),Windows_NT)
    SHELL := cmd
endif

rwildcard=$(foreach d,$(wildcard $(1:=/*)),$(call rwildcard,$d,$2) $(filter $(subst *,%,$2),$d))

INPUT_JavaFileStorageTest-AS = $(call rwildcard,src/java/android-filechooser-AS/app/src,*) $(call rwildcard,src/java/JavaFileStorage/app/src,*) $(call rwildcard,src/java/JavaFileStorageTest-AS/app/src,*.java)

However, I noticed that:

  • while on linux this is rather fast (cannot perceive the duration)
  • on Windows this is actually very slow. (10 seconds)
    [SHELL is voluntarily set to cmd on windows because the user might not have a POSIX shell in its path].

Any idea why this? How can I improve this?

This should work with both GNU make 3.x & 4.x (because on macOS it is version 3.x that is shipped in the devel command line tools, there is no 4.x there)

EDIT

After investigation the problem wasn't the recursive wildcard. I could speed up by running make --no-builtin-rules or adding MAKEFLAGS += --no-builtin-rules in the Makefile, or adding .SUFFIXES: (with empty value). This removed all the lag observed on Windows.

usilo
  • 305
  • 2
  • 10
  • 1
    The value of `SHELL` is irrelevant here because you don't invoke any shell commands. You could try replacing this with a call to Windows `find` when on Windows; maybe it has some tricks that make it faster than the brute force method. But I know of no way to improve the speed. Windows filesystems are just slow. – MadScientist Dec 18 '22 at 14:05
  • Actually `find` is not a native command on windows. There is `WHERE` but it isn't shipped in windows until Win7 apparently. – usilo Dec 18 '22 at 15:30
  • There is a native `find` command in Windows: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/find which is what I was thinking of but I forgot it searches for strings in files not filenames. – MadScientist Dec 18 '22 at 15:54
  • You say 'Windows filesystems are just slow'. Well maybe that's the reason because setting `MAKEFLAGS += --no-builtin-rules` actually removed all the lag. So the problem was not the recursive wildcard. Thanks! – usilo Dec 18 '22 at 19:50

1 Answers1

1

There is a wildcard-rec function in gmtt which maybe does what you want. The big upside of it is that it is platform-agnostic.

include gmtt.mk

INPUT_JavaFileStorageTest-AS := $(call wildcard-rec,src/java/android-filechooser-AS/app/src/**) \
$(call wildcard-rec,src/java/JavaFileStorage/app/src/**) \
$(call wildcard-rec,src/java/JavaFileStorageTest-AS/app/src/**.java)

** is the recursive-descent glob code which means that the routine will step down into all subdirectories.

Vroomfondel
  • 2,704
  • 1
  • 15
  • 29
  • Thank you. Nice suggestion this set of functions. Unfortunately this didn't speed up the thing in a noticeable manner. After investigation the problem wasn't the recursive wildcard. I could speed up by running `make --no-builtin-rules` or adding `MAKEFLAGS += --no-builtin-rules` in the Makefile, or adding `.SUFFIXES:` (with empty value). It remove almost all the lag (~10sec) – usilo Dec 18 '22 at 19:46