Acknowledged

Relative paths in local variables in jungle files are resolved incorrectly.

According to the jungle reference (see the last paragraph), relative paths in jungle files are resolved relative to the jungle file they appear in. But relative paths in local variables are actually resolved relative to the manifest file. In the "default" setup, the manifest file is in the same directory as the jungle file, so this doesn't usually matter, but when they're not the same, it results in strange behavior.

eg, given a project with monkey.jungle at the root, manifest.xml in the sub-directory manifest, source files in source, and resource files in resources, the following jungle file works:

project.manifest = manifest/manifest.xml

base.sourcePath = ./source
base.resourcePath = ./resources

Note that we have to be explicit about the source and resource paths, because the paths in default.jungle are resolved against the manifest.xml file's directory. So in this case, without explicitly setting sourcePath and resourcePath, it would look for sources in manifest/**.mc, and resources in manifest/resources.

But if you rewrite that file using local variables:

project.manifest = manifest/manifest.xml

source = ./source
resources = ./resources

base.sourcePath = $(source)
base.resourcePath = $(resources)

it now looks for source files in manifest/source and resource files in manifest/resources. In order to make this jungle file work, we have to rewrite it as:

project.manifest = manifest/manifest.xml

source = ../source
resources = ../resources

base.sourcePath = $(source)
base.resourcePath = $(resources)

This is clearly not what the documentation says, and is really surprising. You would expect local variables to just be substituted in, and not cause semantic differences.

I realize that changing behavior at this point could break existing projects - although it's unusual for the manifest to be in a different directory from the jungle. But if that's deemed to be too high risk, the documentation should be updated to reflect the actual behavior.

  • Or we could have our cake and eat it too, if they decided to both:

    - document the existing behavior correctly

    - add a new kind of variable substitution which is purely textual: e.g. ${FOO}