search

fpw / avitab

X-Plane plugin that displays a tablet to aid VR usage
GNU Affero General Public License v3.0
299 stars 58 forks source link

Avitab does not build on Mac after recent Xcode update #181

Closed mjh65 closed 4 months ago

mjh65 commented 9 months ago

The Avitab build fails on Mac OSX due to a deprecation warning being treated as an error:

build-third/include/nlohmann/json.hpp:6217:19: error: 'char_traits<unsigned char>' is deprecated: char_traits<T> for T not equal to char, wchar_t, char8_t, char16_t or char32_t is non-standard and is provided for a temporary period. It will be removed in LLVM 18, so please migrate off of it. [-Werror,-Wdeprecated-declarations]
    typename std::char_traits<char_type>::int_type get_character()
                  ^

I don't regularly build Avitab on the Mac. Since the previous build I have updated Xcode (possibly more than once).

The current compiler version is Apple clang version 15.0.0 (clang-1500.0.40.1). This is based on LLVM, who have issued this deprecation warning and explanation: https://discourse.llvm.org/t/deprecating-std-string-t-for-non-character-t/66779

I checked the nlohmann/json project on github to see if a more recent release would fix this. The latest release still has this issue, however the issue has been reported (https://github.com/nlohmann/json/issues/4163) and is being worked on (https://github.com/nlohmann/json/pull/4179).

I think once the issue is fixed in the nlohmann/json library then Avitab should be updated to reference a fixed version.

fpw commented 9 months ago

Fixed by #182

mjh65 commented 9 months ago

I was wondering if this issue should remain open until a proper fix can be put in place by updating to the (next?) version of nlohmann/json? The masking of deprecation warnings should be removed from the CMakeLists file at the same time - it's only really intended as a temporary fix.

fpw commented 9 months ago

Ah, good point.

mjh65 commented 9 months ago

Following on from the temporary fix I submitted for the initial build issue, I have used cmake to generate an Xcode project, and this has highlighted some additional source code issues due to the default setting of the -Wconversion flag in the Xcode project (the flag is not set by default in the normal Makefile generator).

Many of the build errors are due to the use of an unsigned and/or long int variable as an argument to an int parameter. A lot of these are in the Avitab source and could be fixed with an explicit cast (or an overloaded function with an unsigned/long parameter). However, some of the issues are in third-party sources and cannot be easily fixed.

A simple solution is to add the -Wno-conversion compiler flag. This could be done globally in the top-level CMakeLists.txt file. Alternatively the flag could be added only where required (if 3rd party source/header is involved) and the rest of the Avitab sources can be tidied up to remove the warning.

I am happy to create a further PR to address this issue. Which approach is preferred?

fpw commented 9 months ago

Thanks for the investigation! I think that Wconversion is a lot too strict for us, these kind of conversions are not undefined behaviour, they're just implicit. I understand that you might want them in projects that have to take care of functional safety, but we're not building real aviation gear here. I'd favor -Wno-conversion.