Jess Perkins

> or is the project because it is a container itself not subject to the filters of it's parent? This. Containers hold other containers (i.e. solutions hold projects) and blocks...

In case you haven't seen it already, [this page in the user guide](https://premake.github.io/docs/Precompiled-Headers/) explains some hoops to jump through to get PCH working across tooling environments. Not sure if it...

What is the exact error message you're seeing when you try to build? Have you already raised this issue with the maintainers of those projects you mention?

Have you seen [builddependencies](https://github.com/premake/premake-core/wiki/builddependencies) and [makesettings](https://github.com/premake/premake-core/wiki/makesettings)?

Can you please provide a minimal example project that demostrates the issue?

One problem with this approach is that files within the exported Visual Studio project are specified at the _project_ level, and `cfg.buildcfg` isn't meaningful there. You'd really need to do...

I'll defer to someone with more cross-compiling experience, and a more immediate need for it. I'm not opposed to anything suggested here.

Hmm…I guess we'd need to `path.getbasename()` on the virtual path and see if ends with "*" or "**", and then roll those up?

Visual Studio requires an entry for every combination of configuration and architecture, even if they aren't used (or don't even make sense). Hence the extra ProjectConfigurations. I suspect the problem...

FYI, for others finding this issue: the `configuration` call is going to be deprecated shortly as it can't be supported in the next version. If you are able, switching out...