Re: Deprecate AC_LIBTOOL_WIN32_DLL?

[Earnie Boyd]

Charles Wilson wrote:
> The one remaining niggle is this: you *must* specify -no-undefined, or 
> libtool won't even attempt to build a DLL.
I agree.

> But anyway, -no-undefined is a whole separate issue.  As far as 
> AC_LIBTOOL_WIN32_DLL, from the cygwin perspective it can be killed. 
> However, given that there are a lot of projects out there that probably 
> have it in their configure.in's already, perhaps you should leave a 
> dummy (empty) definition?  Or is that not kosher libtool procedure?

Isn't there a method in autoconf to define the macro as deprecated so 
that a warning is issued?

Ah yes:

File: autoconf.info,  Node: Obsoleting Macros,  Next: Coding Style, 
Prev: Depe\
ndencies Between Macros,  Up: Writing Autoconf Macros

Obsoleting Macros
=================

   Configuration and portability technology has evolved over the years.
Often better ways of solving a particular problem are developed, or
ad-hoc approaches are systematized.  This process has occurred in many
parts of Autoconf.  One result is that some of the macros are now
considered "obsolete"; they still work, but are no longer considered
the best thing to do, hence they should be replaced with more modern
macros.  Ideally, `autoupdate' should substitute the old macro calls
with their modern implementation.

   Autoconf provides a simple means to obsolete a macro.

 - Macro: AU_DEFUN (OLD-MACRO, IMPLEMENTATION, [MESSAGE])
     Define OLD-MACRO as IMPLEMENTATION.  The only difference with
     `AC_DEFUN' is that the user will be warned that OLD-MACRO is now
     obsolete.

     If she then uses `autoupdate', the call to OLD-MACRO will be
     replaced by the modern IMPLEMENTATION.  The additional MESSAGE is
     then printed.