Windows port: additionally set PATH in common.mk

Windows doesn't know about LPATH, but PATH is part
of it's .dll search order.

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Revert "Windows port: Make g-ir-annotiotion-tool, g-ir-doc-tool and g-ir-scanner 'relocatable' at runtime."

It's a bit too soon for this one, misunderstood review on irc.
Apologies for the mess!

This reverts commit 0102c517c44d3e8fc3baf2394cb92281511941e3.

Windows port: Make g-ir-annotiotion-tool, g-ir-doc-tool and g-ir-scanner 'relocatable' at runtime.

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: g-ir-scanner: Accept -m flags

Some pkgconfig files contain these flags on Windows, for example
gtk+-3.0.pc has -mms-bitfields in it's Cflags. Nothing is done yet
with these though, we only accept these flags for now...

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: disable barapp test program on Windows

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: set CAIRO_LIBS in LIBADD, not LDFLAGS

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: Export all symbols on Windows.

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: the tmpfile is going to be an exe...

... on Windows, so take care of the extension.

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: dont't build gi-dump-types...

... on Windows, as it uses gio-unix.

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: Do not append '/usr/share' to _xdg_data_dirs...

... on Windows as it points to the MinGW installation directory,
which doesn't have any .gir files to start with anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: compute GOBJECT_INTROSPECTION_LIBDIR at runtime.

Otherwise, we fail to properly locate the typelibs, because on Windows
the value of GOBJECT_INTROSPECTION_LIBDIR depends on where Glib has been
installed. Due to the nature of how we handle software that depends on
Glib on Windows (it is recommended that each program bundles it's private
copy), we're working in a "multi-prefixed" environment. Hence the value
computed at build time will most likely not even exist at runtime.

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: cmph_time.h includes sys/resource.h which is not available on Windows.

So only include it when WIN32 is not defined.

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: Work arount MSYS weirdness where it changes --libtool= command line arguments.

This continues to reuse the LIBTOOL variable from automake if it's set,
but works around some MSYS weirdness: When running g-ir-scanner, MSYS
changes a command-line argument --libtool="/bin/sh ../../libtool" into
--libtool=c:/opt/msys/1.0/bin/libtool. So just use sh.exe without path
because we already "know" where the libtool configure produced is.

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: Simplify _giscanner's .pyd file extension handling.

By simply using -shrext ".pyd".

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: set CAIRO_SHARED_LIBRARY in configure.ac

Both when x$have_cairo_gobject = xyes and x$have_cairo = xyes.

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: check for OS_WIN32 in configure.ac

Without repeated output created by AC_MSG_CHECKING([for Win32])

https://bugzilla.gnome.org/show_bug.cgi?id=620566

Windows port: Use an improved python.m4

- AM_CHECK_PYTHON_HEADERS macro now allows PYTHON_INCLUDES to be overridden
  from an environment variable and
- the new AM_CHECK_PYTHON_LIBS macro to check for ability to link against
  libpython. This also allows PYTHON_LIBS and PYTHON_LIB_LOC to be overridden
  from their respective environment variables.

This allows gobject-introspection to be built with MinGW/MSYS by doing:

PYTHON_DIR="/c/Python27"
SRC_DIR="/d/dev/gnome.org/checkout/gobject-introspection/src"
...
PYTHON_INCLUDES="-I${PYTHON_DIR}/include/" \
PYTHON_LIBS="-L${PYTHON_DIR}/libs/ -lpython${PYTHON_VERSION}" \
PYTHON_LIB_LOC="${PYTHON_DIR}/libs/" \
"${SRC_DIR}/configure" \

https://bugzilla.gnome.org/show_bug.cgi?id=620566

common.mk: Drop incorrect $(EXEEXT) extension on scripts

It only applies to native binaries.

Let the user override the default compiler with the CC env variable

Fix compilation with mingw

grealpath.h defines GetFullPathNameA() as windows.h is
not imported, but for gitscanner.c, windows.h is imported and the compiler
throws an error.

windows: Use the real python version instead of an hardcoded one

windows: Fix extension of g-ir-compiler to include EXE

gi-dump-types: New uninstalled debugging program

Usage: ./_build/gi-dump-types g_object_get_type

girffi: Remove unnecessary sys/mman.h include

While we're here move config.h to the top for consistency.

regress: Fix wrong type of variable in regression test

https://bugzilla.gnome.org/show_bug.cgi?id=658075

Regenerated GLib annotation cache

Regenerated from glib fe4fc3e8b5a5ad8d4113c4df1fe8e0e9f295035e

Install docbookdescription.py

https://bugzilla.gnome.org/show_bug.cgi?id=657686

configure: Post-release version bump

gimarshallingtests.h: Remove unimplemented functions

The new missing-element-type warning triggers for these.

build: Update prepare-minor-release to use xz compression

scanner: Don't try to copy c:type if we're parsing (element-type)

Commit 81abc2eb63317003a11d1484e84698a37e8ec035 tries harder to keep
the c:type if it was overriden by a (type) annotation.  However, the
_resolve() function was also called for (element-type), which had
undesirable effects - we'd copy the container c:type to the element
type.

Fix this by splitting out the c:type preservation to only happen when
processing toplevel types.

https://bugzilla.gnome.org/show_bug.cgi?id=656931

scanner: Remove some dead debugging code

Fix warning for missing (element-type)

While looking for a different bug, I noticed that the introspectable
pass lists was missing GSList.  And the warning was never set up
to fire anyways.  Fix it and add a test.

Add make-check-passed to gitignore

Use INTROSPECTION_SCANNER_ENV in Makefile.introspection

Add a make-check check to pre-commit hook

Avoid most of the special-casing of GObject.Object in the scanner

There were some cases of handling GObject and GInitiallyUnowned which
were not necessary.  Removing special cases from them simplified code
and as a bonus it added 'GObject::notify' signal into GIR, which was
not there previously.

https://bugzilla.gnome.org/show_bug.cgi?id=657446

add regression test for skipped #define

Add a regress test for a method returning GPtrArray

Revert "xlib: fix the type of XID"

This reverts commit 3553cd0a4631f1b57fb608e3f3f78a1a0cfd602a.

Turns out it was wrong, XID is 64 bit on a 64 bit system. Plus
the scanner doesn't like multiple level typedefs.

xlib: fix the type of XID

XIDs are CARD32, which corresponds to guint32 on all platform, not
gulong (which is 64 bit on x86_64). Fix that, and use alias indirection
to more accurately reflect the typedefs.

https://bugzilla.gnome.org/show_bug.cgi?id=643620

configure.ac: Do not generate template files

It's not needed as the project uses inline comments
for documentation.

configure.ac: Generate xz tarball with ustar format by default

Update autotools configuration

Replace deprecated autoconf macros
Use new libtool syntax

autogen.sh: Use autoreconf instead custom script

Fix g_irepository_find_by_gtype() for GDK_TYPE_RECTANGLE

Complement fix for g-ir-scanner which converts every GdkRectangle
gtype to CairoRectangleInt.  Make sure that C-side API is also aware
of this workaround.

Use case requiring this patch:

When binding implementation wants to get/set property, it can use either
GI-based approach (g_property_info_xxx() funcs), or just GLib facilities.
Although former is probably preferred, there are cases when latter is still
needed (e.g. gstreamer uses dynamic properties, which are not present in the
gir).  In this case, binding implementation queries the type of the propertyb
(using g_object_class_find_property()), it gets GDK_TYPE_RECTANGLE,
and without the patch it cannot map it to any known type.

https://bugzilla.gnome.org/show_bug.cgi?id=655423

Properly handle GParamSpec and descendants

GParamSpec is introspected as fundamental class, and all GObject
classes derived from it (e.g. GParamSpecChar) are marked as such.

https://bugzilla.gnome.org/show_bug.cgi?id=656440

Update annotations from glib git 2cd3c200687751c9cc26774f650b7651bffcc598

Remove MAINTAINERS and add DOAP

add back the fixed_array_out_struct test

tests: build tests only on make check

Use automake's check_ prefix and avoid putting anything nontrivial in
BUILT_SOURCES so that tests are build only on make check.

The dummy -rpath in AM_LDFLAGS in tests/scanner/Makefile.am is needed to
force libtool to build shared libraries for check_LTLIBRARIESS targets
(automake builds check_LTLIBRARIES as static by default); see
http://lists.gnu.org/archive/html/automake/2005-10/msg00107.html

https://bugzilla.gnome.org/show_bug.cgi?id=657066

doctool: Disable tests for now

They don't work for multiple reasons, and there is still debate
about how the formatting etc. will work.

docbookdescription.py: Fix for PEP-8 compliance

Update annotations from glib git d51e0615f9a6c1aa1898c46f2cf3135ca5ccd463

Add 'Since:' tags to the newly added GIEnumInfo methods

Regenerate Gio/GLib/GObject annotations

Ran misc/update-glib-annotations.py against current glib master.

Add tests for newly added warnings

g-ir-scanner now warns for invalid (element-type) annotations
in GPtrArray and in GByteArray. Test that.

tests/doctool: Remove MALLARD_DIRS from BUILT_SOURCES

so we don't generate the test docs when doing a plain build

Disallow non byte types for GByteArrays

Similarly to GPtrArrays, GByteArrays can only contain bytes. Emit
a warning if an inconsistent (element-type) is placed, and ensure
that the default is guint8 if nothing is added. This way bindings
can support GByteArrays without special casing them.

https://bugzilla.gnome.org/show_bug.cgi?id=652753

Forbid GPtrArrays holding non-pointer types

It should be safe for bindings to assume that GPtrArrays hold only
pointers (or values as big as it), so there is no need to go through
hoops for converting smaller integers when marshalling.
Libraries that need arrays of integers should use GArray.

https://bugzilla.gnome.org/show_bug.cgi?id=652753

Docbookwriter: signal flags

In DocBookWriter, remove DocBookEntity and just use the ast nodes directly.

For docbook, make the id attributes the same regardless of language. Only user visible strings should change between C and Python.

Descriptions support for docbook writer.
Includes support for escaping (but not double escaping) entities and CDATA sections.

Add descriptions from GIR to docbook writer.

Allow enums and bitfields to have static methods

This uses the same backcompat machinery that was introduced for static
methods for non-class types, so this change does not break users of the
existing presentations.

New libgirepository API:

    g_enum_info_get_n_methods
    g_enum_info_get_method

https://bugzilla.gnome.org/show_bug.cgi?id=656499

Teach scanner's girparser about fundamentals

Make sure that fundamental attribute and associated
functions (ref-func, unref-func, set-value-func and get-value-func)
are parsed, otherwise we fail reparse-validating girs containing
fundamentals.

giscanner: Allow passing additional include dirs when parsing a gir

tests/doctools: Properly clean the temporary mallard files

tests/doctool: Update the -expected dirs

tests/doctool: Make sure we regenerate the mallard code when testing

[doctools] use 'or' instead of 'and' when checking for func or constructor

treat constructors like methods when generating the label

[doctool] use different templates for method vs. function output

configure.ac: Change to tar-ustar because PAX gives problems in OpenBSD

Also, it's what other GNOME modules use

tests/doctool: Better way of copying the .gir

configure.ac: Add tar-pax to AM_INIT_AUTOMAKE

output namespace.class.methodname for python methods in the doctools

tests/doctool: Compare -expected directories instead of single files

fix up Python doc backend to output correct names

tests/doctool: Switch to test the mallard formatter

first pass at python backend for doc tools

tests/doctool: Add the right -expected files to dist

tests/doctool: Update expected files

g-ir-doc-tool: Fix PEP-8 issues

g-ir-doc-tool: print class declaration line in Python

giscanner/mallardwriter: Adding experimental Mallard output to g-ir-doc-tool

g-ir-doc-tool: Use namespace.class for Python

g-ir-doc-tool: Ignore for now properties with no known type

g-ir-doc-tool: Use the array type when rendering [element-type]

g-ir-doc-tool: Add -expected test for Python docbook

g-ir-scanner: Stop going up the hierarchy once we reach GObject

Make sure we have UNINSTALLED_INTROSPECTION_SRCDIR when running tests

Regress-1.0-expected: Update for previous change

annotationparser: Don't eat lines that look like parameters outside param list

If we're done parsing parameters, previously we would simply eat lines that looked like
    @foo: blah blah

Example is in gtkcssprovider.c.

https://bugzilla.gnome.org/show_bug.cgi?id=656504

Recognize constructors ending in 'newv'

Like gtk_list_store_newv and gtk_tree_store_newv.

https://bugzilla.gnome.org/show_bug.cgi?id=656460

Merge remote-tracking branch 'origin/gir-docbook'

Conflicts:
.gitignore
tests/scanner/Regress-1.0-expected.gir

Try harder to preserve c:type

When we replace a type using annotation we should keep
the ctype of the original type.

Make sure signal works when there isn't one specified

Make sure signal works when there isn't one specified

g-ir-doc-tool: Add support for varargs