Re: HEAD not building

[Malcolm Tredinnick <malcolm commsecure com au>]

On Fri, 2003-10-03 at 04:25, Havoc Pennington wrote:
> On Thu, 2003-10-02 at 11:35, Dan Winship wrote:
> > 
> > It would be cool if there were some way to define what version of the
> > API you want deprecation warnings against, for modules that need to be
> > able to build against multiple versions of gtk/gnome/whatever. Eg,
> > evolution 1.4 has always had the warning:
> > 
> >         e-shell.c: In function `e_shell_construct':
> >         e-shell.c:1306: warning: implicit declaration of function
> >         `bonobo_activation_active_server_register'
> > 
> > because bonobo_activation_active_server_register was deprecated in
> > libbonobo 2.2. But we can't fix it because evolution needs to compile on
> > GNOME 2.0 machines too. What we really want is something like
> > "FOO_DISABLE_DEPRECATED_IN_2_0", etc
> 
> Yeah, that might be nice. I believe what you're supposed to do right now
> is only define the DISABLE_DEPRECATED in builds from CVS, not in tarball
> releases. Then developers just stick to latest libs.
> 
> > On a related note, it would be great if there was some easy way to turn
> > on deprecation warnings for every library in the platform. (Evolution
> > sets G_, GTK_, BONOBO_, and GNOME_DISABLE_DEPRECATED, but misses GDK_,
> > BONOBO_UI_, GCONF_, and LIBGLADE_DISABLE_DEPRECATED). Maybe a
> > GNOME_PLATFORM_2_4_DISABLE_DEPRECATED define that all libraries would
> > obey?
> 
> For sure, that would be a good thing.

One problem with this approach is that you are going to end up with a
lot of defines (one for each major GNOME release, at least) in a lot of
libraries. Not a disaster, but not particularly neat.

Another solution that will work right now is to add a macro to
gnome-common so that something calling something like
GNOME_NO_DEPRECATED() in you configure.in will put all the necessary
defines in config.h. I shall add this shortly (on the weekend).

Packages not using gnome-common can then copy the appropriate macro to
their acinclude.m4 or their m4/ directory and use it as well. Packages
not using autoheader and config.h would be on their own, but they
already have problems by that point anyway.

Cheers,
Malcolm