macOS Support

[tingspain]

Hello @aybe,

First of all, great job. I was wondering if there is any plan to support macOS? I would love to help if you give me some hint.

Thanks in advance

[aybe]

Hello @tingspain , thanks! 😀

While myself I'm no macOS user nor have knowledge about this platform, sure, why not!

Though I know nothing about the platform, I believe one will have to do the following:

Native side:

The libraries imgui and implot would have to be built through CMake instead of being Visual Studio's vcxprojs.

There is a preliminary CMakeList.txt that you can base yourself on.

Being dynamic libraries means they should import imgui as opposed to having it internally as you can see on many other projects.

This is trivial to do as both native projects are well written, for instance, in implot it's just a matter of defining the preprocessor constants IMGUI_API=__declspec(dllimport); beside the usual stuff of setting includes.

Ideally, each library should define the build version in them, not mandatory but useful to identify them.

Once you more or less get that done (because getting these platform-specific stuff genericized in CMake is sometimes tricky or not worth the trouble), I guess you can proceed to the next big step.

Managed side part 1:

The generator shared library should be updated to also allow generating bindings for macOS:

https://github.com/aybe/DearImGui/blob/develop/DearGenerator/Library.cs#L259

The list of native targets supported by CppSharp are here and Darwin is supported:

https://github.com/mono/CppSharp/blob/main/docs/UsersManual.md?plain=1#L44

At this point, you should run dearimgui-build.cmd
(though I believe that .cmd might need a rewrite as it's Windows specific) and see if CppSharp does not fail, if it does not, see what's been diffed in the different generated .g.cs files, these changes will appear as not committed in the repository.

From there, proceed to next step.

Managed side part 2:

Something I'm not sure about but I guess that the DllImport will then become different than Windows'.

Which means that the Roslyn code rewriter will need an update.

While it has become a necessity to get that Roslyn code rewriter for the sole reason that x86 decorated names differ than x64 decorated names, hence, it's mandatory; I don't think it'd be wise to have twice as much for another platform, i.e. imports for

• x86 windows
• x64 windows
• x86 mac (not sure if that still exist)
• x64 mac
• x86 linux (in the future, maybe)
• x64 linux (in the future, maybe)

A rough idea that deserves to be tested would be maybe that the Roslyn rewriter could write that for instance:

[DllImport(
#if WINDOWS
"imgui"
#elif MAC
"imgui.dylib" /* or whatever it will be called */
#endif
) ,...]

But as you can see in the generated bindings, sometimes CppSharp generates different code for x86 and x64 for things like IntPtr and so on.

Ultimately, that has to be tested, if the simplest is to add new __Internal32 and __Internal64 structs for macOS (if it's the case, the syntax rewriter will need a trivial update to accommodate that), I'm okay with that, the already huge 25K LOC block will probably double in size, more or less... 😅

I guess that's pretty much there is to do, not incredibly difficult but time-consuming and patience-consuming.

Additionally

You may eventually want to take a look at the tips I gave to @KCoen which brought up the docking branch 🎯:

#14

#15

Last but not least, I did upgrade CppSharp packages so as to not use the specific version from the GitHub registry however, CppSharp now fails with an exception as shown in #17.

For this very issue, the simplest might be to simply revert that commit and generate bindings again, there's been tiny differences between both version. And of course, reference the GitHub registry in your IDE, the instructions to add a custom NuGet registry are provided by GitHub, here.

And building managed class libraries for anything else but Windows should probably be a breeze, even Visual Studio provides that today in a C# project properties window.

Finally, upgrading NuGet packages to be multi-platform is probably not a difficult thing to achieve.

---

I guess I forgot nothing, making changes to that project aren't too difficult, it's just a matter of patience.

The rule of thumb generally is, less is more; if you see ending with tons of platform-specific fixes, it's probably the wrong route.

Building the native binaries should be easy, the generators themselves probably need zero changes, the Roslyn rewriter will definitely need an update but it shouldn't be a big deal in itself.

The potentially huge changes in the generated bindings is not something to be afraid of, for instance, Visual Studio Code compare feature is generally very useful to diff these changes. For these, you should see in bin\Debug files like imgui-backup-ISO date.g.cs to ease comparison or simply use the ones of your VCS, e.g. GitHub Desktop or anything else.

Good luck! 🤞 If you have any other questions, feel free to ask, I'll try to answer them.

[tingspain]

@aybe, Thank you very much for your reply, especially for your very detailed explanation. I really appreciate it. I am gonna give it a try and if I need any help I will ask you. I really want to have ImGui and ImPlot (and later ImNodes) running fully multi-platform. I am gonna be busy for two weeks, but after that, I will focus on work on it.

[aybe]

@tingspain

Sorry for the late answering, been pretty busy...

Sure, no problem, take your time!

I've been trying to look for ways onto cross-compiling dylib from Windows, but thus far, there doesn't appear to be a way unless I missed it; so, unfortunately I cannot give it a try from here.

[tingspain]

@aybe,

Dont worry, I really want to contribute. I have already compiled all ImGui dylibs (for cimgui, cimplot, cimnodes and cimgizmo)

[ds5678]

Ideally, this could be automated into a GitHub action. Then, we would always have compiled builds.

[aybe]

@tingspain

yep, okay :)

[aybe]

@ds5678

That sounds like a really good idea, I guess they're cross-compile ready and could do all the heavy lifting.

If anyone wants to look at it, it will be more than welcome!

[ds5678]

A convenient feature would be to have platform guard attributes applied to all the generated structs and classes. That would warn library users in the IDE about the current platform restrictions.

[global::System.Runtime.Versioning.SupportedOSPlatform("windows")]