Autogen.sh was grepping for the obsolete macro AM_CONFIG_HEADER, which
was replaced by AC_CONFIG_HEADERS in configure.ac. As a consequence it
was not calling autoheader, and then causing automake to fail if
config.h.in was not already present.
ListBase was throwing a NullReferenceException in DataMarshal() due
to the fact that Reflection was being used to find the adapter name
of the interface generated by the bindings, which has recently
changed [1].
[1] 6cb03440c1
This regression surfaced after 82a957bc9d [1],
when many collections were migrated to generic collections. HashTables
simply return null when queried for certain key, while Dictionary objects
throw KeyNotFoundException.
The regression could be noticed, more particularly, when trying to
compile the gtk3 branch of the gudevsharp project [2].
[1] 82a957bc9d
[2] https://github.com/mono/gudev-sharp/commits/gtk3
For example gtk_drag_start allows a null Gdk.Event so we need to marshal
it to IntPtr.Zero instead of throwing a NullReferenceException
Cherry-picked from the gtk-sharp-2.12 branch.
Also:
* improving naming consistency
* obsolete old/broken stuff
* clean up tabs/space mix
NOTE: this removes the wrapper caches for Pattern and Surface as
there was no reliable way to clear them.
This is a merge from changes in Mono.Cairo in mono 3.2.
To be able to do this, Name property of GenBase class is now virtual, so
that it can be overriden in InterfaceGen with the new name.
Adapters, however, are still classes and then need special care as such
(cannot use the 'Name' property anymore), but this improves a bit the
readability of some parts of the code as the *Implementor and *Adapter
suffixes are now concentrated in just two new properties of GenBase and
not repeated all over the place.
What seemed to be a race condition (because of not happenning 100% of
the times) ended up being an early garbage collection of a delegate that
was still referenced by an unmanaged struct without having a managed
counterpart [1].
The consequence of this was a NullReferenceException happening in a line
which didn't have a dereference of a null object. The way to reproduce it
deterministically 100% of the times was setting the env var MONO_NO_SMP.
[1] http://www.mono-project.com/Interop_with_Native_Libraries#Memory_Boundaries
With automake version 1.13.2 (which comes in debian testing/jessie),
we were starting to get these warnings by default:
...
Running automake --foreign ...
atk/glue/Makefile.am:16: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
gio/glue/Makefile.am:11: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
gtk/glue/Makefile.am:18: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
gtk/gui-thread-check/profiler/Makefile.am:8: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
pango/glue/Makefile.am:13: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
sample/opaquetest/Makefile.am:18: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
sample/valtest/Makefile.am:18: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
Running autoconf ...
...
We simply follow the warning's recommendation of using AM_CPPFLAGS instead
(CPP meaning C PreProcessor, not C Plus Plus), as explained in
http://www.gnu.org/software/automake/manual/html_node/Program-Variables.html
The deprecation of INCLUDES has been very long there already (since 2002,
therefore Automake 1.7), and we already depend on automake 1.10.
