#956 DUNE_DEPRECATED should have a variant with a message

Metadata

Property	Value
Reported by	Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de)
Reported at	Sep 28, 2011 17:01
Type	Bug Report
Version	2.1
Operating System	Unspecified / All
Last edited by	Jö Fahlke (jorrit@jorrit.de)
Last edited at	Oct 5, 2011 14:58
Closed by	Jö Fahlke (jorrit@jorrit.de)
Closed at	Oct 5, 2011 14:58
Closed in version	Unknown
Resolution	Implemented
Comment

Description

I am constantly annoyed by stuff which gets deprecated, but there is no indication of what is the new and shiny way to do things. Reading http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html I recently stumbled over the fact that GCC supports a message parameter for attribute((deprecated)) and thought this is a great idea. Without further ado, here is my patch which adds a DUNE_DEPRECATED_MSG("message") macro to config.h. I'm not completely sure whether my auto%§$-foo is good enough and whether it also works for non-GCC compilers, but at least for me it works.

Attachments

• 0001-add-DUNE_DEPRECATED_MSG-string-macro-to-make-depreca.patch

clang appears to support this, too:

http://clang.llvm.org/docs/LanguageExtensions.html#deprecated

The patch in it's current for does not provide the full functionality: a) attribute((deprecated) and b) attribute((deprecated(msg)) must be tested separately and compiler which only support (a) should implement (b) via a fallback to (a).

It would be great, if you could update your patch accordingly.

Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:

here it goes

Attachments

• 0001-add-DUNE_DEPRECATED_MSG-message-macro.patch

Thank you. Patch looks fine. I'll apply it...

The current patch is defective. With g++-4.4 it results in the following lines in config.h:

/* how to create a deprecation warning with an additional message / / #undef DUNE_DEPRECATED_MSG */(msg)

I'm using the following settings in my dunecontrol.opts:

CONFIGURE_FLAGS="--enable-parallel CXXFLAGS='-ggdb3 -O0 -Wall -Wno-missing-braces' CPPFLAGS=-UNDEBUG --enable-documentation= --with-alberta=/usr --with-alugrid=/home/joe/src/dune-noopt/ALUGrid-inst --with-ug=/home/joe/src/dune-noopt/UGinst --enable-shared=yes --without-metis --with-parmetis=/usr --enable-extra-utils --with-superlu-dist=/home/joe/src/dune-noopt/superlu_dist --with-superlu-dist-lib=/home/joe/src/dune-noopt/SuperLU_DIST-inst/lib/libsuperlu_dist_2.5.a" AUTOGEN_FLAGS="--ac=2.59 --am=-1.9"

(At least this is what it boils down to, the full opts file is a bit more complicated and is attached for completeness.)

Attachments

• dunecontrol.opts

Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:

Hm, seems to be that your compiler doesn't know about attribute((deprecated)) at all. This is an example of why I hate autotools,

http://www.gnu.org/s/hello/manual/autoconf/Defining-Symbols.html

says something about a "parenthesized argument list" in AC_DEFINE, but they do not specify what this means. anyway, if both tests fail, I get something like

/* how to create a deprecation warning */ #define DUNE_DEPRECATED

/* how to create a deprecation warning with an additional message */ #define DUNE_DEPRECATED_MSG(msg)

in my config.h, which seems fine IMHO. did you run dune-autogen on all modules?

Actually, it does support attribute((deprecated)) without argument:

/* how to create a deprecation warning */ #define DUNE_DEPRECATED attribute((deprecated))

For completeness, here is my config.log and full config.h.

Attachments

• config.log
• config.h

Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:

yes I understand. but you have to re-duncontrol all your dune modules after this patch, because it seems that for some modules you're using the unpatched dune_deprecated.m4 and for some the new one. the result is that AC_DEFINE_UNQUOTED for the unpatched modules is not executed in configure, which makes makes config.h syntactically incorrect, because autoconf in its magnificence does not understand C macros with arguments (and even if it would, if you had some code which actually uses DUNE_DEPRECATED_MSG would fail because the macro would be undefined). please tell me what dunecontrol says!

I did the re-dunecontrol stuff. And this happens already with dune-common's config.h so the other modules are not involved.

Oh, wait. I'm forcing older autoconf and automake versions. I did this specifically to discover problems with older autotools that we still claim to support. According to our homepage we support automake (>= 1.5) and autoconf (>= 2.50). I'm using automake 1.9 and autoconf 2.59.

Defining a macro with arguments probably requires special care with older autoconf version.

Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:

hm, any ideas? it would be possible to put the deprecated macros into a separate header file (e.g. dune/common/deprecated.hh) and only define HAVE_ATTRIBUTE_DEPRECATED and HAVE_ATTRIBUTE_DEPRECATED_MSG in config.h. this would require to include the header before using the macros, though...

In this case you might end up with a large set of different DOES_SUPPORT_THIS and DOES_SUPPORT_THAT flags. Every subtle difference in the syntax would result in a new config.h entry. I don't consider this a viable solution.

Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:

hm, any ideas? it would be possible to put the deprecated macros into a separate header file (e.g. dune/common/deprecated.hh) and only define HAVE_ATTRIBUTE_DEPRECATED and HAVE_ATTRIBUTE_DEPRECATED_MSG in config.h. this would require to include the header before using the macros, though...

Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:

sorry for the duplicate comment, pressing reload is probably ill-advised sometimes.

okay, here is the next iteration. I think it works out quite nicely with the HAVE_* macros because in this approach, there is only one central place to go for DUNE_DEPRECATED (-> dune/common/deprecated.hh). that file already exits for doxygen but now it is authorative. Jö: could you please verify that it works with the old autotools?

Attachments

• 0001-add-DUNE_DEPRECATED_MSG-message-macro.patch

Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:

oops. I forgot to remove a #warning directive in deprecated.hh which was added for debugging purposes...

Attachments

• 0001-add-DUNE_DEPRECATED_MSG-message-macro.patch

Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:

oops again. the fallback for DUNE_DEPRECATED_MSG was nothing instead of DUNE_DEPRECATED. stupid me!

Attachments

• 0001-add-DUNE_DEPRECATED_MSG-message-macro.patch

What is the revision these patches apply to? I tried with the current trunk (r6508), but neither git am nor git apply nor patch are able to apply the patch.

The base revision for the patch was apparently (r6507), the last version that didn't include this feature at all.

At least config.h looks fine with the new patch:

/* does the compiler support attribute((deprecated))? */ #define HAS_ATTRIBUTE_DEPRECATED 1

/* does the compiler support attribute((deprecated("text"))? / / #undef HAS_ATTRIBUTE_DEPRECATED_MSG */

I'm going to try a full build of dune-common and some other module tomorrow.

Making deprecated.hh mandatory for DUNE_DEPRECATED may give some people headaches, though. Not sure this is a good idea. DUNE_DEPRECATED_MSG is another matter, since it is a new feature there should be no problem with requiring deprecated.hh for that.

@christi: I thought lots of DOES_SUPPORT_THIS and DOES_SUPPORT_THAT macros for every relevant difference in syntax was exactly what config.h was invented for?

You should consider the situation similar to that of the SHARED_PTR_HEADER macro. You just want one definition to describe the feature and not a load of macros for each possible implementation.

Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:

@Jö: nothing changes in respect to include deprecated.hh . it is included at the bottom of config.h by means of AH_BOTTOM.

Oh, yuck, that sounds like an ugly hack. That might cause problems when multiple macros start fighting over their position using AH_BOTTOM.

On the other hand, that problem may be more potential than actual. I have no really hard argument against it, and no time to invent something better. So lets go with it.

(Test is still underway.)

Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:

That might cause problems when multiple macros start fighting over their position using AH_BOTTOM.

that should not matter.

http://www.gnu.org/s/hello/manual/autoconf/Autoheader-Macros.html

says:

""" There is rarely a need for something other than

 AH_BOTTOM([#include <custom.h>])

"""

Since it should be possible to include headers in arbitrary order, provided that config.h was included first, the exact ordering of the include statements does not matter (if it does it is a bug in the header file).

OK, test check basically out.

One interesting difference in the "make check" output is:

@@ -1248,10 +1248,7 @@ not implemented for 3d yet: no check is performed check_mesh: checking mesh 'DUNE AlbertaGrid' checking done; no error detected -alberta_alloc: ERROR in alloc.c, line 77

•                can not allocate 48.13 KB

•                called by newBlock in ../Common/memory.c, line 84

-/bin/bash: Zeile 4: 22810 Abgebrochen

${dir}$

tst +/bin/bash: Zeile 4: 3011 Bus-Zugriffsfehler

${dir}$

tst FAIL: test-alberta3d-refine

1 of 1 tests failed

I have no idea what's happening there though, and since the test failed before already I suppose it doesn't matter. I'm going to apply the patch in a minute.

Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:

thanks a lot for testing and discussing this :)

Applied in trunk@6509

Status changed to closed