Legacy / Settings Relative Paths

[jcolicchio]

Fixes #979

This PR causes included yaml to adjust LegacyTarget's workingDirectory to be relative to the including yaml file

[jcolicchio]

@yonaskolb I'd actually appreciate your input here on this "fix" before I add tests. It's something that'd benefit my use case, but I'm not sure if it's generally a good idea when including other yaml files, that we change the HEADER_SEARCH_PATHS to be relative to the new location. Thoughts?

[yonaskolb]

Hi @jcolicchio, thanks for this. Yeah I'm a bit hesitant to apply changes to HEADER_SEARCH_PATHS, especially as it would be a breaking change for many. I'm happy to include the working directory though as that's an oversight, even though it's also technically breaking, which the changelog entry can indicate with Breaking

[jcolicchio]

@yonaskolb sounds good! I've undone my change to HEADER_SEARCH_PATHS and updated the changelog 👍

[yonaskolb]

Is this supposed to be AnotherProject, or is this correct?

[jcolicchio]

This is correct — when generating AnotherProject directly from the AnotherProject folder, the working directory for the target is ‘.’, but when including it in another project in a different directory, that project’s target will have a working directory relative to the other project.

In other words, regardless of where the generated project ends up, the working directory for the target declared in this folder will evaluate to this folder