From: Duncan C. <dun...@wo...> - 2009-01-08 13:29:31
|
On Tue, 2009-01-06 at 16:48 +0100, Axel Simon wrote: > Hi Peter, > > you seem to have added a new meaning or variant of the --disable- > deprecated flag. > I think the --disable-deprecated will pass DISABLE_DEPRECATED or > something like that to CPP when pre-processing the gtk.h header file > and will thus omit all sorts of definitions. Yes. I think it was me who added that a couple years ago. > If we really wanted to make this flag work with Gtk2Hs, then we would > have to omit all deprecated definitions depending on the version > number of Gtk+ that we compile against. I don't think that's necessary. We can consider deprecated everything that is deprecated in the latest gtk version. We do not need to make things deprecated depending on the version of gtk we're building against. > This seems to be too much trouble. It is already enough work to > exclude all new functions for older Gtk+ versions since this has to be > tested against all older Gtk+ versions. Fully supporting the > DISABLE_DEPRECATED flag is IMHO too much work for the benefit it gives > developers. It worked fine until gtk+ 2.14 when a few more things were deprecated. I expect the incremental work level is not too high. > A cheaper interpretation of --disable-deprecated would be to remove > all functionality in Gtk2Hs that we think should not be used anymore. > Examples are the Event module which is replaced by EventM and also > all module in TreeList/ are deprecated. I think this is your > interpretation, but I just want to make sure that I understand what > you're doing. Have you removed anything related to passing > DISABLE_DEPRECATED to CPP? I'd suggest things in the Haskell code we want to deprecate should just use the DEPRECATED pragma rather than omitting them from the build. Deprecating entire modules can be done by adding a DEPRECATED pragma above the module declaration. I'd advocate reserving DISABLE_DEPRECATED for the cpp define for the Gtk header files. Duncan |