@whaeck Alternatively, I think you can just delete those two lines instead of adding a preprocessor guard.

~/NJOY21/bin/_deps/hana-adapter-src$ git diff
diff --git a/src/include/boost/hana/traits.hpp b/src/include/boost/hana/traits.hpp
index 983bdf83..1f19a5a3 100644
--- a/src/include/boost/hana/traits.hpp
+++ b/src/include/boost/hana/traits.hpp
@@ -68,7 +68,6 @@ BOOST_HANA_NAMESPACE_BEGIN namespace traits {
     constexpr auto is_trivially_copyable = detail::hana_trait<std::is_trivially_copyable>{};
     constexpr auto is_standard_layout = detail::hana_trait<std::is_standard_layout>{};
     constexpr auto is_pod = detail::hana_trait<std::is_pod>{};
-    constexpr auto is_literal_type = detail::hana_trait<std::is_literal_type>{};
     constexpr auto is_empty = detail::hana_trait<std::is_empty>{};
     constexpr auto is_polymorphic = detail::hana_trait<std::is_polymorphic>{};
     constexpr auto is_abstract = detail::hana_trait<std::is_abstract>{};
diff --git a/src/test/type/traits.cpp b/src/test/type/traits.cpp
index dd2e3d7e..80647999 100644
--- a/src/test/type/traits.cpp
+++ b/src/test/type/traits.cpp
@@ -54,7 +54,6 @@ int main() {
     hana::traits::is_trivially_copyable(s);
     hana::traits::is_standard_layout(s);
     hana::traits::is_pod(s);
-    hana::traits::is_literal_type(s);
     hana::traits::is_empty(s);
     hana::traits::is_polymorphic(s);
     hana::traits::is_abstract(s);

I think it is better to update the hana-adapter with a more recent version, or just change the dependency to point to a specific hana release instead. This is something that we started doing in the NJOY components that are currently under development (although I assume that things like ENDFtk and ACEtk might be suffering from this issues as well).

Do any of you see this when compiling ENDFtk and/or ACEtk python bindings or unit tests?

Seeing how out of date the hana-adapter repository was with hana and also not wanting to go through the commits on the hana-adapter or resolve merge conflicts, I was proposing a simple solution to a silly problem (something deprecated causing a build failure that wasn't even used anyway).

I was just trying to build NJOY21 on Ubuntu-22.04. At this point I am going to give up trying to solve the various warnings, errors, and out-of-date repository dependencies that gcc-11.2 is squawking about :)

Having looked through some of the other posts, I am given the impression that it is better to embrace NJOY2016 for now and begin the NJOY2021 adventure anew in the future :)

I understand trying to use a simple fix but in the end it could give us more headache when we actually update the dependency to a more recent one. My stance on a lot of these things is often to do it right the first time ;-)

Updating the dependency will take a lot of time though - since it impacts the other components that depend on it as well.

And yes, we do advice to continue to use NJOY2016 instead of NJOY21 since NJOY21 does not offer any relevant feature that NJOY2016 cannot do. Our current development approach involves prioritising NJOY2016 maintenance and developing NJOY components like ENDFtk, ACEtk and resonance reconstruction with python bindings that can be deployed to users more quickly than actual modernised modules (ENDFtk and ACEtk are good examples here). These components also allow us to achieve more objectives than just modernise NJOY (e.g. ACEtk is being used for ACE file testing and perturbation - something that NJOY's ACER module cannot do).

... do it right the first time ;-)

I hope I get to see the day where any of us (myself included) can accomplish this 😝

Sounds like a good development plan, thanks Wim!

I forgot to mention this: deprecation warnings get turned into errors due to the -Werror flag while compiling. You can actually switch that off in the NJOY21 CMakeLists.txt file. Removing the -Werror will revert to warnings again, and allow for compilation to continue. Either way, I'm testing ENDFtk right now with gcc 11.2 and I do see that deprecation warning so I will have to address it there.