| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=752272
|
| |
|
|
|
|
|
| |
I forgot to add the fallback definitions in case we're not using GCC;
without them, anybody using non-GCC compilers will get a build error.
https://bugzilla.gnome.org/show_bug.cgi?id=752272
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to be able to deprecate macros, but right now the best we can do
is to wrap them with things like:
#ifndef CLUTTER_DISABLE_DEPRECATED
# define A_MACRO_I_WANT_TO_DEPRECATE ...
#endif
Which requires adding a new symbol to the build, and will cause a build
error instead of a compiler/pre-processor warning.
Fortunately, we can use the _Pragma() keyword introduced by C99 and
supported by GCC to add a warning to the output, while leaving the macro
itself intact.
GCC does not have a "deprecated" pragma, so we have to use a generic
warning; this also means we cannot do nifty things like concatenating
strings and the like, as we do for the "deprecated" attribute.
The macro deprecation symbol should have the same affordances as the
function deprecation one, and evaluate to nothing if the required
version is lower than the current version; or if the global toggle for
deprecation warnings is in effect.
|
| |
|
|
|
|
|
|
| |
GCC has some optimization for the inclusion guard, but they only work if
the check is the outermost one.
We're fairly inconsistent because of historical reasons, so we should
ensure that we follow the same pattern in every public header.
|
| | |
|
| |
|
|
| |
The 1.22 cycle did start a while ago.
|
| | |
|
| |
|
|
|
| |
We are going to switch to compiler annotations to determine the
visibility of the symbols.
|
| |
|
|
| |
We're still going to do a 1.x release cycle.
|
| | |
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=685028
|
| |
|
|
|
|
| |
The introspection scanner has become slightly more annoying, in the hope
that people start fixing their annotations. As it turns out, it was the
right move.
|
| |
|
|
|
|
|
|
|
|
| |
The ClutterCanvas content implementation should be used instead, to
avoid stringing along the ClutterTexture API and implementation.
This change requires some minor surgery, as the deprecated section
already contains an header for the previously deprecated methods; plus,
we don't want to deprecate clutter_cairo_set_source_color(). This means
creating a new header to be used for Cairo-related API.
|
| |
|
|
|
| |
Otherwise we'll not warn on deprecations introduced in the current
development cycle.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
GLib introduced macros that allows defining the lower and upper bounds
of the API to be used by application code.
The lower bound allows to define the minimum version that will trigger
deprecation warnings; the upper bound defines the maximum version that
will trigger compiler warnings for unavailable symbols.
This scheme allows gradually porting application code to a new version
of the API, especially in case of resynchronization after multiple
development cycles.
|
| |
|
