Can't build imgui on OSX with nim 1.4+

[melMass]

• What is the current behavior?

It fails while trying to build my imgui based nim project using a nim version greater than 1.06 (I think, 1.4+ for sure)

• Please provide the steps to reproduce and if possible a minimal demo of the problem

I've yet to try the C version (I did not compile cimgui) but the CPP build returns

error: invalid argument '-std=gnu++14' not allowed with 'Objective-C'

Here is my compile command just in case some flags are missing/not supported:

nim cpp --threads:on --outdir:dist/bin -r src/mtb/bin/test_imgui.nim

• Please tell us about your environment

  • Version: 1.4.2
  • OS: MacOS
  • Bindings: OpenGL & GLFW & ImGui
  • Backend: CPP

• Other information (e.g. detailed explanation, stack traces, related issues, suggestions on how to fix, links for us to have context, eg. StackOverflow, docs.gl, documentation, etc)

Is there a way to use the metal backend I'm not sure how this could be done using Nim?

[oakes]

Seems to not be just IMGUI...any nimgl project built with the C++ backend seems to fail with that error. My guess is that it might be GLFW. Maybe we don't need to link to all these frameworks? I wonder if one of them is bringing in objective-c...

[nixfreak]

Ok , I figured out how to compile green_window , the example on the readme without errors on osx big surr now

nim c --cc:llvm_clang -r green_window.nim

I will look into imgui since I'm wanting to figure those bindings out also.

Looks like its a compiler bug

Talking to one of the devs on "#nim"
now, for some reason, nim tries to add the flags gnu++14 also to the command line to compile the objective-C file for imgui. that command line flag is invalid for objective c. therefore compilation fails. cause, bug in the compiler. you can't do anything about it, other than reporting it as a regression. this did not happen before the optimization was introduced.

[tonogram]

You can work around this issue by creating your own build script. Here's a minimal example.

[stream-punk]

You can work around this issue by creating your own build script. Here's a minimal example.

@tonogram the example isn't there anymore. Do you know another? Was it specific to this problem or just any expample? I am new to nim, so I am not sure how to proceed.

I also found a workaround:

cp ~/.nimble/pkgs/nimgl-1.3.2/nimgl/private/cimgui
make
cd ~/the/project
cp ~/.nimble/pkgs/nimgl-1.3.2/nimgl/private/cimgui/cimgui.dylib .

The backend has to be C for that workaround.

[tonogram]

@davidsonder I have edited my original comment with a fixed version of the link. Sorry for the inconvenience.

I also found a workaround

The backend has to be C for that workaround.

The problem in question only occurs on the C++ backend because the compiler will attempt to compile/link some MacOS graphics libraries, which are written in Objective-C. The compiler trips up when doing this, because it attempts to use certain flags that are not compatible with Obj-C. This is most likely an oversight or bug in the Nim compiler, as it is what is generating the flags that are being passed to the C++ compiler.

The C backend works because it skips this step, opting to instead rely on the dylib for the necessary functionality. However, the caveat is that you will have to manually build the dylib that it requires, and you will also have to bundle a copy of this dylib when distributing your program in order for it to function.

My build script example essentially just sits between the Nim compiler and the C++ compiler, and discards the invalid flags whenever an Obj-C file is being used. It's a very simple fix, but it gets the job done. I am using a much more complicated version of this script in a project I'm working on.

[stream-punk]

@tonogram thanks a lot, that worked straight away.

SEQ_DECL_SIZE is a bug in nim? There should be another case for C++ in nimbase, right?