Open lacasseio opened 4 years ago
Which macros are you expecting? By default the only ones really are UNICODE
, but that's easily changable in VS, and would break our project would massively break if that was specified by default.
You are right that we don't want to add macros that can't be removed or that are unexpected. Long time users of the Gradle native support are used to the fact that no macros are provided by default. However, for users migrating from Visual Studio (MSBuild) this behaviour is a bit counter-intuitive. The solution will most likely be part of a windows-runtime
plugin that provides expected defaults for developing typical components under Windows.
This issue affects the Visual Studio IDE integration in a different way where Intellisense doesn't know about some macros. We simply need to ensure the macros are in sync with the component. We may need to query the compiler to properly configure the VS projects.
During Windows development, there is a set of well-known and mostly expected macros to be available during compilation. There are several ways we could go about this approach:
1) Automatically pre-populate the macros map for the variant with Windows operating system family. Users can remove default values if they choose to. We could offer either remove all the predefined macros or a specific one. 2) Option 1 only if a Windows runtime plugin is applied like
dev.nokee.windows-runtime
. 3) Provide convenience methods that need to be called to get for the macros to be configured.I believe what would align with our current approach is option 2. By default, the native plugins are mostly runtime agnostic, meaning no runtime is assumed. A Windows runtime plugin would fit well in explicitly adding the Windows capability to the project, hence preconfigure the components to be opinionated for Windows.
However, I can see a source of confusion where users can declare target machines for Windows but wouldn't get the expected convenience from a vanilla Windows development process. To help with the messaging, we could (and will in the future) introduce error parsers that could direct the user to the right solution for common errors. For example, compilation failures on Windows without Windows runtime plugin applied could hint the user to apply the runtime plugin with links to the documentation to understand if it's the right solution for them.