boost geometry C++14 R 3.6 patch about bh

[Jean-Romain]

Everything is currently fine on CRAN. Did you notice any trouble with Boost 1.78?

[dcooley]

:waves back: - googlePolylines is currently all OK on CRAN. Let me know if the reverse depenency checks give me any grief and I'll update as well.

[eddelbuettel]

I appreciate you working through this.

At present, CRAN has other packages where R-oldrel fails on Windows because of the toolchain. Nobody is really complaining. Come April and R 4.1.0, the current rtools4 toolchain with gcc-8 and g++-8 will become old-rel. The current r-devel also just switched to C++14 as the default compilation (where available, this would include Windows if I am not mistaken), and my inclination is actually to ... simply sit pat and wait this out.

What you did (including your modified headers before the official one, and relying on the include to prevent overwriting your definitions) is good. Maybe #undef`-ing the include guard and doing the include afterwards is better if other definitions are needed -- I don't know.

[Jean-Romain]

I know that it is not a big deal and the CRAN does not complain about it. But I believed that the old toolchain will still live for longer than that. I didn't know that it will be retired in April. My patch suddenly becomes less valuable 😞 . Anyway I'm sure lot of people still use R 3.6...

On my side I still have clang-USBAN + Solaris errors. The Solaris error comes out of nowhere, is not directly linked to lidR but seems to be caused by old libraries (gdal and proj) and I can't reproduce it. Because I can't fix Solaris error I tried to fix the windows-oldrel in attempt to get more chance to get my next minor update accepted... 🎲 Anyway, in the worst case I learned a lot doing so. Nothing lost.

By the way the good way to target gcc < 5 specifically seems to be

#if defined(__GNUC__) && (__GNUC__ < 5) && !defined(__clang__) && !defined(__llvm__) && !defined(__INTEL_COMPILER)

because clang defines __GNUC__ (SO question)

[eddelbuettel]

Hi @Jean-Romain just checking in as I will likely work on Boost 1.78 in the next few days preparing a release. From checking lidR and rlas at CRAN, everything seems peachy now without issue stemming from package BH -- correct?

(And ditto for googlePolyline -- 👋 at @dcooley ?)

[eddelbuettel]

Have not gotten to it -- have to mark student projects this weekend. Should get to it by Monday and run reverse depends checks hopefully early next week.

[eddelbuettel]

Sounds good. I have the package ready, but the reverse-depends box is currently tied up with another Rcpp run. Will get to BH 1.78.0 tomorrow but do not expect any trouble.

[eddelbuettel]

I think we can close this as the old issue (for 1.75.0) it was raised for got sorted (as "promised") with the disappearance of the older build platform, and neither 1.75.0 or now 1.78.0 seem to pose issue. Yay for good code.