[Mono-dev] Use eglib as a default for mono 2.6

Miguel de Icaza miguel at novell.com
Thu Apr 23 17:05:50 EDT 2009


    Been thinking some more about this:

> The short answer is: we will never switch to eglib as default.
> The primary reason is that the eglib symbols would interfere with the
> real glib symbols used by so many mono apps.
> What needs to happen is the following:
> 1) take a data structure implemented in eglib and copy it to mono/utils,
> renaming the file and the symbols to have mono_ instead of g_ at the
> start.
> 2) replace all the uses of that glib data structure in the mono code
> with the new equivalent mono_ version
> 3) repeat the above for all the data structures, functions and GLib types
> used by mono

    I think that this suggestion is pretty invasive, both in terms of
making the internal changes, and to the SVN history, for very little

    I went and looked at the public API that we expose, and we found
that only a handful of glib data types are exposed in our public
contract [1].   If we are going to break the API, we might be able to
just introduce the new public entry points defined in terms of a new
structure but keep all the internals building against eglib with the
suggestion that someone had on the list to remap symbol names.

   This has several benefits:

	* We can still alternate between glib and eglib.

	* We can choose to make eglib the default.

	* We would not clash between eglib and glib.

    The cons are:

	* We still need to deprecate/break the API for the functions
	  listed in [1]

	* We need to continuously monitor the public API to ensure
	  that no new glib structures are ever exposed.

This of course assumes that the basic glib data types like gint32 and so
on are always compatible between glib and eglib.   But this I think is
something that we can depend on, since if they were not identical today
we would have much worse problems. 

There are still a handful of places where glib is better than eglib,
tiny bits here and there, but nothing really major.

We could also make sure that the structures map 1 to 1 to the Glib
structures for the ones that we use, that would prevent the need to even
break the API when using the remapping macros. 

But I can see why this last one might make some people uncomfortable.

[1] This is the list of public API entry points that expose Glib data

metadata/assembly.h:void      mono_assembly_foreach    (GFunc func, gpointer user_data);
metadata/verify.h:GSList* mono_image_verify_tables (MonoImage *image, int level);
metadata/verify.h:GSList* mono_method_verify       (MonoMethod *method, int level);
metadata/verify.h:void    mono_free_verify_list    (GSList *list);
utils/mono-hash.h:    GEqualFunc    key_equal_func);
utils/mono-hash.h:    GEqualFunc    key_equal_func,
utils/mono-hash.h:    MonoGHashGCType type);
utils/mono-hash.h:    GEqualFunc    key_equal_func,
utils/mono-hash.h:    GDestroyNotify  key_destroy_func,
utils/mono-hash.h:    GDestroyNotify  value_destroy_func);
utils/mono-hash.h:    GHFunc    func,
utils/mono-hash.h:    GHRFunc    func,
utils/mono-hash.h:    GHRFunc    func,
utils/mono-hash.h: MonoGRemapperFunc func,
utils/mono-logger.h:mono_trace (GLogLevelFlags level, MonoTraceMask mask, const char *format, ...);
utils/mono-logger.h:mono_tracev (GLogLevelFlags level, MonoTraceMask mask, const char *format, va_list args);
utils/mono-logger.h:mono_trace_set_level (GLogLevelFlags level);
utils/mono-logger.h:mono_trace_push (GLogLevelFlags level, MonoTraceMask mask);
utils/mono-logger.h:mono_trace_is_traced (GLogLevelFlags level, MonoTraceMask mask);
utils/mono-logger.h:#ifdef G_HAVE_ISO_VARARGS
utils/mono-logger.h:#define mono_trace_error(...) mono_trace(G_LOG_LEVEL_ERROR, \
utils/mono-logger.h: __VA_ARGS__)
utils/mono-logger.h:#define mono_trace_warning(...) mono_trace(G_LOG_LEVEL_WARNING, \
utils/mono-logger.h: __VA_ARGS__)
utils/mono-logger.h:#define mono_trace_message(...) mono_trace(G_LOG_LEVEL_MESSAGE, \
utils/mono-logger.h: __VA_ARGS__)
utils/mono-logger.h:#elif defined(G_HAVE_GNUC_VARARGS)
utils/mono-logger.h:#define mono_trace_error(format...) mono_trace(G_LOG_LEVEL_ERROR, \
utils/mono-logger.h:#define mono_trace_warning(format...) mono_trace(G_LOG_LEVEL_WARNING, \
utils/mono-logger.h:#define mono_trace_message(format...) mono_trace(G_LOG_LEVEL_MESSAGE, \
utils/mono-logger.h: mono_tracev(G_LOG_LEVEL_ERROR, mask, format, args);
utils/mono-logger.h: mono_tracev(G_LOG_LEVEL_WARNING, mask, format, args);
utils/mono-logger.h: mono_tracev(G_LOG_LEVEL_MESSAGE, mask, format, args);

> After that is done, remove eglib from svn, remove the glib dependency
> from the mono build, change the libmono version number since the ABI and
> API breaks, fix all the bugs that showed up because of the changes,
> make a new release.
> The library version change will happen together with the other API
> breaks we have planned (which depend on the new GC and a few other minor
> changes in the runtime), but that stuff is not required for your needs.
> So far nobody has volunteered for the tasks 1-3.
> lupus

More information about the Mono-devel-list mailing list