GNOME Bugzilla – Bug 659427
Move deprecated code to a separate directory
Last modified: 2011-09-19 02:04:26 UTC
See patches.
Created attachment 196896 [details] [review] Move GAllocator/GMemChunk to separate file Create a deprecated/ directory that we can start moving ancient chunks of code to. Start with GAllocator, GMemChunk and related APIs. Also drop all mention of them from the docs.
Created attachment 196897 [details] [review] Move deprecated GRel to deprecated/ Keep the docs for now, though. We'll remove them after a few more cycles.
Created attachment 196898 [details] [review] Move deprecated GCompletion to deprecated/ Keep the docs for now, though. We'll remove them after a few more cycles.
Review of attachment 196897 [details] [review]: ::: docs/reference/glib/tmpl/glib-unused.sgml @@ +1,1 @@ +<!-- ##### SECTION ./tmpl/allocators.sgml:Image ##### --> oops. this got tucked in by accident.
Review of attachment 196896 [details] [review]: Looks ok to me. ::: docs/reference/glib/glib-docs.sgml @@ -124,3 @@ <xi:include href="xml/relations.xml" /> <xi:include href="xml/caches.xml" /> - <xi:include href="xml/allocators.xml" /> The alternative here would be to move the docs off to a 'deprecated' section. One argument for keeping the docs around as long as the code is still there is that people need the docs to learn that things are deprecated, and what to use instead. Might not be that relevant for these cases... ::: glib/Makefile.am @@ +113,3 @@ +deprecated_sources = \ + deprecated/gallocator.c Not sure about starting to mix recursive and non-recursive make here.
Review of attachment 196897 [details] [review]: ::: glib/grel.c @@ +35,3 @@ +#include <glib/gtestutils.h> +#include <glib/gstring.h> +#include <glib/gslice.h> A little odd that a new include shows up here - why was it not needed before ?
Review of attachment 196898 [details] [review]: ::: glib/gcompletion.c @@ +35,3 @@ +#include <glib/gstrfuncs.h> +#include <glib/gmessages.h> +#include <glib/gunicode.h> Also, any reason you are switching the include order around here ? I think we are generally going config.h this-module.h system headers needed glib headers No ?
Review of attachment 196897 [details] [review]: ::: glib/grel.c @@ +35,3 @@ +#include <glib/gtestutils.h> +#include <glib/gstring.h> +#include <glib/gslice.h> I discovered the gslice.h is included in gmem.h inappropriately. I plan to remove it from there, which will cause problems here.
Review of attachment 196898 [details] [review]: ::: glib/gcompletion.c @@ +35,3 @@ +#include <glib/gstrfuncs.h> +#include <glib/gmessages.h> +#include <glib/gunicode.h> I tend to favour "other glib headers" before system headers. I don't think it matters either way, though.
Review of attachment 196896 [details] [review]: ::: docs/reference/glib/glib-docs.sgml @@ -124,3 @@ <xi:include href="xml/relations.xml" /> <xi:include href="xml/caches.xml" /> - <xi:include href="xml/allocators.xml" /> I kept the docs for the GRel and GCompletion cases for this reason. This code is so old at this point... ::: glib/Makefile.am @@ +113,3 @@ +deprecated_sources = \ + deprecated/gallocator.c We have a few cases of this around GLib already. We did it to get GWakeup into gio from ../glib/gwakeup.c and some of our testcases use it to directly #include .c files for purpose of testing internal API.
ok then. seems fine.
All committed.