Thanks, but I might not fully understand then: I checked and we don't do this for GTSAM_ENABLE_BOOST_SERIALIZATION, but we can still branch on that in code. Why is GTSAM_USE_BOOST_FEATURES different?

Thanks, but I might not fully understand then: I checked and we don't do this for GTSAM_ENABLE_BOOST_SERIALIZATION, but we can still branch on that in code. Why is GTSAM_USE_BOOST_FEATURES different?

Oh, right. The GTSAM_ENABLE_BOOST_SERIALIZATION didn't generate a build error for me, but it should be added as well. Fixed.

Well, I guess my question was the other way :-) Why can we branch on GTSAM_ENABLE_BOOST_SERIALIZATION currently? And could we use the same mechanism to branch on GTSAM_USE_BOOST_FEATURES? It seems the add_definitions was not needed for GTSAM_ENABLE_BOOST_SERIALIZATION?

AFAIK both identifiers/macros were always not defined in the code. My linter confirms that but to prove it I added this to one of the examples:

...checked out my first commit (with just GTSAM_USE_BOOST_FEATURES fixed), made sure the flag is ON and built:

The output:

...and you are right. For some reason both are ON 😕 So why it's not working during compile time?

right :-)
No idea ! Sleuthing required!
But if we find a]out why we can avoid the “add_definitions” step.
Note: it requires #if and not #ifdef. Maybe there is a straggling #ifdef ?

Note, your test is compile time. All macro pre-processing is gone at runtime.

OK, got it. GTSAM is using https://github.com/borglab/gtsam/blob/develop/gtsam/config.h.in
It creates a config.h that needs to be included if one want to use the CMake variables. To include was missing from that one specific file. Thank you @dellaert, great questions!

FYI add_definitions is an inefficient approach. Please see #1944 for details.

Also sorry I didn't see this before, was busy with other stuff. Else we could have fixed this sooner. :)