Environment PATH in master BFF can be specified per compiler/config

[doanamo]

• Add FastBuildSettings.Additional[Win|Osx]EnvironmentPaths for modifying PATH in global environment settings
• Add FastBuildSettings.AdditionalCompilerEnvironmentPaths for modifying PATH in specific compiler node
• Add FastBuildSettings.AdditionalConfigEnvironmentPaths for modifying PATH in specific compiler configuration (affects its linker/librarian, but not the compiler itself)
• Allow FastBuildSettings.SetPathToResourceCompilerInEnvironment to set different rc.exe directory paths for each compiler configuration instead of globally
• Add SimpleExeWithRC functional test case for ensuring that FastBuildSettings.SetPathToResourceCompilerInEnvironment switch continues working correctly

This change aims to reduce scope in which additional PATH entries are added - per compiler or its configuration instead of globally. It also removes limitation where only one path to resource compiler could be added using FastBuildSettings.SetPathToResourceCompilerInEnvironment, which would result in an exception if multiple configurations for different MSVC versions were present in single master BFF.

Hi!

Let me explain the main motivation for this change - In our use case of Sharpmake we are targeting a platform that uses older version of MSVC, but at the same time wanted to have newest MSVC version used for other platforms, while also having all platforms generated in single solution under FastBuild instead of having separate solutions targeting different DevEnv. This is one of our changes that was needed to allow targets with different DevEnv in single solution, which fixes limitation of SetPathToResourceCompilerInEnvironment that could not handle multiple paths to different versions of rc.exe because it was adding them to global .Environment.

Separate AdditionalCompilerEnvironmentPaths and AdditionalConfigEnvironmentPaths are needed because ObjectList node does not support .Environment property unless it is part of Compiler node that was passed to it.

To be honest, I think it may be redundant to have AdditionalCompilerEnvironmentPaths because dependencies that can be found under PATH should be specified in compiler's .ExtraFiles instead for FastBuild distribution to work correctly. However, since FastBuild has .Environment property for Compiler node, this is added here for completeness.

Disclaimer: I made sure to use proper delimiter for environment paths on OSX, but I only tested this change on Windows.

[belkiss]

Heya! Thanks for the PR :)

At a first glance this looks fine, I'll try and find some time to try it out on a few internal projects. Bonus point for adding a test!

As a side note, I'm leaning towards exposing the method creating the compiler node keys, since your new properties in FastBuildSettings now rely on that as well, and it would feel nicer instead of typing "Compiler-x64-vs2019" to write Bff.GetCompilerKey(Platform.win64, DevEnv.vs2019) or something like that, wdyt?

Cheers!

[doanamo]

I think it would be a great idea! Something similar would be very useful for getting compiler config name, because AdditionalConfigEnvironmentPaths requires a name from BFF that starts with . character, since this is the key that is used internally - so not ideal.

Quick look at the code tells me that some modifications may be needed across all platform implementations to have such methods exposed. Is it something that you would like me to try implementing as part of this change?

[belkiss]

Is it something that you would like me to try implementing as part of this change?

No it's not something that is a blocker, I was just saying it would be nice ;)

[doanamo]

I will try looking into it 👍