Mac Unity Editor - compiler error due to symbol duplication (due to compiler directives)

[PetrBodnar]

Describe the bug Error The namespace 'PlayEveryWare.EpicOnlineServices' already contains a definition for 'EOSCreateOptions' due to incorrect compiler directives in Runtime/macOS/Core/MacOSPlatformSpecifics.cs and Runtime/Windows/Core/WindowsPlatformSpecifics.cs

To Reproduce Steps to reproduce the behavior:

1. Create empty project on Mac
2. Select Windows Intel 64 bit as target platform
3. Add EOS package of version 3.1.3
4. See error

Desktop (please complete the following information):

• mac OS Intel 14.1.1 (23B81)
• Editor
• Unity Version 2021.3.14f1
• Plugin Version 3.1.3

Additional context Runtime/macOS/Core/MacOSPlatformSpecifics.cs has condition: #if (UNITY_STANDALONE_OSX || UNITY_EDITOR_OSX) && !UNITY_EDITOR_WIN Runtime/Windows/Core/WindowsPlatformSpecifics.cs has condition: #if (UNITY_STANDALONE_WIN || UNITY_EDITOR_WIN || UNITY_WSA_10_0) Both conditions are true in Mac editor, and duplicate symbol error occurs (On Windows only the condition in WindowsPlatformSpecifics.cs is true)

Temp fix - change condition to #if (UNITY_STANDALONE_OSX) && !UNITY_EDITOR_WIN in MacOSPlatformSpecifics.cs

[PetrBodnar]

Temp fix - change condition to #if (UNITY_STANDALONE_OSX) && !UNITY_EDITOR_WIN in MacOSPlatformSpecifics.cs

But with this fix Runtime/Android/Core/AndroidPlatformSpecifics.cs and Runtime/iOS/Core/IOSPlatformSpecifics.cs doesnt build from Mac Editor for Android and iOS , respectively, due to errors like "EOSCreateOptions" not defined

Looks like #if... conditions in all ***PlatformSpecifics.cs need to be re-written, to work without taking current Editor platform in account, and only take a selected build platform in account.

I will research and write here more precisely next week

[PetrBodnar]

Hi, did I understood correctly that https://github.com/PlayEveryWare/eos_plugin_for_unity/pull/673 will fix this issue?

[paulhazen]

Hi, did I understood correctly that #673 will fix this issue?

Yes - that PR will indeed fix the issue. We should have it merged into development by the end of the day - and by the end of the week we will have a new release that incorporates the change.

[paulhazen]

I can confirm that this issue is resolved in our upcoming release 3.2.0, which will be coming out early next week. Consequently, I'm marking this issue as "pending" and closing it out.