After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659427 - Move deprecated code to a separate directory
Move deprecated code to a separate directory
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-09-19 01:42 UTC by Allison Karlitskaya (desrt)
Modified: 2011-09-19 02:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Move GAllocator/GMemChunk to separate file (33.50 KB, patch)
2011-09-19 01:42 UTC, Allison Karlitskaya (desrt)
reviewed Details | Review
Move deprecated GRel to deprecated/ (7.46 KB, patch)
2011-09-19 01:42 UTC, Allison Karlitskaya (desrt)
reviewed Details | Review
Move deprecated GCompletion to deprecated/ (3.43 KB, patch)
2011-09-19 01:42 UTC, Allison Karlitskaya (desrt)
reviewed Details | Review

Description Allison Karlitskaya (desrt) 2011-09-19 01:42:09 UTC
See patches.
Comment 1 Allison Karlitskaya (desrt) 2011-09-19 01:42:11 UTC
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.
Comment 2 Allison Karlitskaya (desrt) 2011-09-19 01:42:15 UTC
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.
Comment 3 Allison Karlitskaya (desrt) 2011-09-19 01:42:21 UTC
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.
Comment 4 Allison Karlitskaya (desrt) 2011-09-19 01:44:43 UTC
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.
Comment 5 Matthias Clasen 2011-09-19 01:48:10 UTC
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.
Comment 6 Matthias Clasen 2011-09-19 01:49:46 UTC
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 ?
Comment 7 Matthias Clasen 2011-09-19 01:51:42 UTC
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 ?
Comment 8 Allison Karlitskaya (desrt) 2011-09-19 01:55:03 UTC
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.
Comment 9 Allison Karlitskaya (desrt) 2011-09-19 01:56:13 UTC
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.
Comment 10 Allison Karlitskaya (desrt) 2011-09-19 01:58:18 UTC
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.
Comment 11 Matthias Clasen 2011-09-19 01:59:22 UTC
ok then. seems fine.
Comment 12 Allison Karlitskaya (desrt) 2011-09-19 02:04:26 UTC
All committed.