Pcl: [MacOS CI] Issue with cmath, boost and Apple

[kunaltyagi]

Your Environment

• Operating System and version: MacOS 10.14 (CI)
• Compiler: AppleClang 11
• PCL Version: HEAD

Context

MacOS CI is red

Current Behavior

/usr/local/include/boost/math/special_functions/fpclassify.hpp:552:17: error: no member named 'isnan' in namespace 'std'; did you mean simply 'isnan'?
        return (std::isnan)(x);
                ^~~~~
/usr/local/include/boost/math/special_functions/math_fwd.hpp:885:9: note: 'isnan' declared here
   bool isnan BOOST_NO_MACRO_EXPAND(T t);
        ^

[SergioRAgostinho]

Probably the same as #2601

[kunaltyagi]

Possibly. Apple loves breaking non XCode tool-chain. We'll most likely have to wait for an update?

[SergioRAgostinho]

Any idea of where to report this? It feels like something that the team from Azure pipelines should be aware. They have too many azure-pipelines-* repos :/

[shrijitsingh99]

Any idea of where to report this? It feels like something that the team from Azure pipelines should be aware. They have too many azure-pipelines-* repos :/

An issue can be created at virtual-environments since azure-pipelines-image-generation has been replaced.

Possibly. Apple loves breaking non XCode tool-chain. We'll most likely have to wait for an update?

Can we not switch to using the Xcode bundled toolchain instead of being dependent on updates to the VM-image?
I made a quick demo (CI Status).

[kunaltyagi]

switch to using the Xcode bundled toolchain

That's a possibility and IMO probably better for MacOS. If your build succeeds, please go ahead with a PR 😄

[shrijitsingh99]

So I did some more testing and only the Xcode toolchain with macOS SDK 10.15 works, rest all configurations are broken and are not working.
So if we switch to the default Xcode version and use the latest SDK on the VM, future builds should not break.

[kunaltyagi]

How is your CI using XCode? XCode.app isn't available on the PR I tried to emulate you

[shrijitsingh99]

c is small in Xcode.
It should be XCODE_APP_PATH=`/Applications/Xcode.app', you cant use XCODE_APP_PATH=`ls -d /Applications/XCode*since there are multiple versions of Xcode available.

[SergioRAgostinho]

Side note: Ci appears to be running green again for OSX builds.

[kunaltyagi]

Where? #3732 just ended on red

[kunaltyagi]

@shrijitsingh99 Thanks a lot. This seems to have done the trick. Also, I added Catalina CI 😄 (1 more hour on 1 pipeline)

[SergioRAgostinho]

Here #3731, but it was false alarm. The entire CI ran in 14 minutes. :)

[kunaltyagi]

The entire CI ran in 14 minutes

What wouldn't I give to have a build time of 14 minutes....

It doesn't build common or anything, and doesn't throw an error either. Might be a bug hiding in CMake.

CMake config log since CI deletes old logs

-- The C compiler identification is AppleClang 11.0.0.11000033
-- The CXX compiler identification is AppleClang 11.0.0.11000033
-- Check for working C compiler: /Applications/Xcode_11.3.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode_11.3.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
--   outofcore: Requires visualization.
--   examples: Code examples are disabled by default.
--   people: Requires octree.
--   simulation: Disabled by default.
--   tests_2d: Requires filters.
--   tests_common: Requires common.
--   tests_features: Requires 2d.
--   tests_filters: Requires octree.
--   tests_geometry: Requires common.
--   tests_io: Requires octree.
--   tests_kdtree: Requires common.
--   tests_keypoints: Requires filters.
--   tests_people: Requires octree.
--   tests_octree: Requires common.
--   tests_outofcore: Requires visualization.
--   tests_recognition: Requires ml.
--   tests_registration: Requires filters.
--   tests_search: Requires octree.
--   tests_surface: Requires octree.
--   tests_segmentation: Requires ml.
--   tests_sample_consensus: Requires search.
--   tests_visualization: Requires octree.
--   tools: Disabled manually.
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_apps_3d_rec_framework
    BUILD_apps_cloud_composer
    BUILD_apps_in_hand_scanner
    BUILD_apps_modeler
    BUILD_apps_point_cloud_editor

[shrijitsingh99]

The entire CI ran in 14 minutes

What wouldn't I give to have a build time of 14 minutes....

It doesn't build common or anything, and doesn't throw an error either. Might be a bug hiding in CMake.

CMake config log since CI deletes old logs

Yeah, it could not find boost dependency. Shouldn't we have something in the CI to catch such types of error i.e. if it just skips building packages for some reason? Cause it gives wrong indication that the CI was successful even though it wasn't.

[kunaltyagi]

Shouldn't we have something in the CI to catch such types of error

Should: yes, but maybe it's compromised or doesn't exist. Maybe FindBoost is quiet or some other bug is present in CMake

[shrijitsingh99]

Shouldn't we have something in the CI to catch such types of error

Should: yes, but maybe it's compromised or doesn't exist. Maybe FindBoost is quiet or some other bug is present in CMake

Yeah so to catch all of this. We could have a script run at the end of the tests to see if actually all the modules listed were actually built and fail if any module was skipped.