it seems that there is still a bit of confusion about DUNE_DEPRECATED: this define should be set in the applications config.h where the compiler features are known. Thus, a program on the application side should start with #include "config.h" #include <dune/stuff/morestuff.hh> so that workarounds for compiler bugs or other crazy tricks can work. We introduced DUNE_DEPRECATED so that the compiler can warn if functions are used which we decided to remove some meeting(s) ago. Otherwise those functions will be scattered thoughout the codebase for ages. Unfortunately, the deprecated-mechanism is a GNU-extension which is why we check for it. The DUNE_CHECK_ALL-test, which both duneapps and dune-tutorial use, includes this check. When icc is used DUNE_DEPRECATED will automatically be defined to nothing. If this does not work, please run "autogen.sh" again (this will fetch the newer tests from Dune) and check if config.h really doesn't mention DUNE_DEPRECATED. If so, please drop me a note. _Please_ don't fiddle with those automatic variables! This will break all the portability magic! As we experienced with Dune under Mac OS X there are a lot of subtle differences between Unices we have to take care of!
We just realised, that on BSD systems _A is defined. This leads to lot of problems in our code as we use _A as a variable name. Then precosessor creates funny code like const M& 0x00001010; instead of const M& _A; The same problem implies for several _"one big charakter" names. So be warned :-)
In the buildsystem quite some shell code is needed. The default shell /bin/sh is supposed to behave the same, no matter which machine you run your script on. Sadly there are some subtile, but still important, differences between the different 'bourne shell' implementations. Therefore it is important to know about possible caveats.