When building `$1_JTREG_BASIC_OPTIONS`, it is assumed that the variable is recursively defined and that thus `+=` is lazy.

```
$1_JTREG_BASIC_OPTIONS += -$$($1_JTREG_TEST_MODE) \
        -verbose:$$(JTREG_VERBOSE) -retain:$$(JTREG_RETAIN) \
        -concurrency:$$($1_JTREG_JOBS) -timeoutFactor:$$(JTREG_TIMEOUT_FACTOR) \
        -vmoption:-XX:MaxRAMPercentage=$$($1_JTREG_MAX_RAM_PERCENTAGE) \
        -vmoption:-Dtest.boot.jdk="$$(BOOT_JDK)" \
        -vmoption:-Djava.io.tmpdir="$$($1_TEST_TMP_DIR)"
  ```

If `+=` is eagerly evaluated, the option -timeoutFactor: will get an empty argument and fail.

The problem is the line: `$$(eval $$(call SetJtregValue,$1,JTREG_BASIC_OPTIONS))` might create the variable `$1_JTREG_BASIC_OPTIONS` "simply expanded" (the expansion will create an assignment using `:=`). Whereas if the variable is not created the first `+=` will be recursive and will work as expected.

One solution to this problem is replacing the three assignments in `SetJtregValue` from `:=` to `=`. This might have other side effects.

A more conservative solution might be to create another macro (thus not changing behaviour where strict evaluation might be needed):
```
define SetJtregRecursiveValue
  ifneq ($$($2), )
    $1_$2 = $$($2)
  else
    ifneq ($$($$($1_COMPONENT)_$2), )
      $1_$2 = $$($$($1_COMPONENT)_$2)
    else
      ifneq ($3, )
        $1_$2 = $3
      endif
    endif
  endif
endef
```