Nikita Kniazev

#307 is the right way, because Boost.TypeInfo is a portable solution to the problem the code is solving.

> You're correct: that's supposed to detect old MSVC versions, checking for defined(BOOST_MSVC) should do the trick also? `defined(__ghs__)` is clearly detecting something different than MSVC

> the entire PPC64 file was accidentally commented out in 2016, so no one has compiled it in years. Is there is a way to cross-compile to that target from...

> * a set of "binutils" capable of targeting powerpc-darwin (which means building them locally and is a little fiddly at present). AppleClang is stripped from PPC support? I don't...

> Having said that, I realise you need a pretty restricted set of functionality - essentially preprocessor + assembler, right? Yes, though I forgot that you guys added `asm/tail_ontop_ppc32_sysv.cpp` thing....

> > (I will see if there's some easier sub-set of tools to do that - but you can be certain that there is nothing available 'out of the box')....

> The API of BOOST_FUSION_ADAPT_ADT doesn't foresee this use, nor the unit tests do. But Spirit's [do](https://github.com/boostorg/spirit/blob/9a8cded55355644c749d6511504b59c048d64de3/test/karma/regression_adapt_adt.cpp#L105-L110) and demonstrates it in an [example](http://www.boost.org/doc/libs/1_65_0/libs/spirit/doc/html/spirit/karma/tutorials/karma_adapted_complex.html). > You can use `val` instead of...

Huh, fusion have test with omitted arguments too https://github.com/boostorg/fusion/blob/f7b90f29817563bf1f3bc6ded860076f8085ba92/test/sequence/adapt_struct.cpp#L158 And produces bunch of warnings http://www.boost.org/development/tests/develop/output/teeks99-09-p-win2012R2-64on64-fusion-msvc-14-1-warnings.html#adapt_adt_named > I could add a check to BOOST_PP_IS_EMPTY to handle this case. I suspect it...

Has to be because of this https://github.com/boostorg/fusion/blob/37ed70fc430cd651732bf761c7443d04d00815d4/include/boost/fusion/adapted/std_tuple/std_tuple_iterator.hpp#L36

https://github.com/boostorg/context/pull/228 should've fixed this (if `clang -arch x86_64 -arch arm64 asm.S` is actually able to produce an universal binary).