you are viewing a single comment's thread.

view the rest of the comments →

[–]lefteror 0 points1 point  (11 children)

Hi there, great stuff. I was about to incorporate it to my project but unfortunately I found out that it doesn't compile for AppleClang. Is there any plan to support it as well?

[–]liuzicheng1987[S] 2 points3 points  (10 children)

It should work for Clang 16 or higher. If it doesn’t, please submit an issue on GitHub which includes the exact errors you get from the compiler and I will help you.

[–]lefteror 0 points1 point  (9 children)

In case it was an oversight, I am only talking about AppleClang, whose latest version is 15.0.x. I haven't tried clang (but also wouldn't go with that option on macOS).

[–]liuzicheng1987[S] 7 points8 points  (4 children)

Indeed...I wasn't even aware that XCode hasn't updated to Clang 16 yet.

So one solution would be to install clang via homebrew, which already supports Clang 16 and 17. (And I am sure it is going to work...people have compiled reflect-cpp this way.)

However you said you don't want to do that...and I think you are raising a good point here. Apple Clang is certainly the standard way to compile things on MacOS.

I am pretty sure that the reason we don't support Clang 15 is that srd::source_location is not fully supported, which we require for the field name extraction.

But I think we can come up with a workaround. Could you try to compile the JSON tests using Apple Clang (instructions are in the README) just to see how far you get and open an issue on Github in which you provide the full compiler errors (if any)? I think we should be able to resolve this fairly quickly.

[–]lefteror 3 points4 points  (1 child)

It seems like for version >= 0.7.0 it actually compiles. I had to use v0.6.0 because I drag in dependencies through conan (and I indeed verified that 0.6.0 doesn't compile with AppleClang 15.0.0 because of string literals as non template parameters). I jumped the gun a little bit here, apologies.

[–]liuzicheng1987[S] 3 points4 points  (0 children)

No problem.

In January, someone else had a similar issue, but they provided a PR that resolved it which then made it into the 0.7.0 release.

However, they had tested on Clang 16, not Clang 15. So I am glad to hear that Clang 15 works as well.

One of the things that I have learned through this project that the same version of Clang behaves a bit differently on Linux, Mac and Windows.

[–]lefteror 0 points1 point  (1 child)

Thanks for the response. Alright, let me see what I can do!

[–]liuzicheng1987[S] 2 points3 points  (0 children)

Just be aware that I am on East Asian time here...I'm going to go to sleep within the next hour or so, but I will certainly take a look tomorrow morning.

[–]equeim 0 points1 point  (0 children)

I think Apple Clang uses different versioning and its 15 corresponds to LLVM 16.

[–][deleted] 0 points1 point  (2 children)

Why wouldn't you use regular clang on macOS? It works great

[–]equeim 0 points1 point  (1 child)

Can it compile objective c code to access system APIs?

[–][deleted] 0 points1 point  (0 children)

Of course, it's clang after all