patch-review

[Stefan Kost]

hi,

there is some stuff that I would like to get second opinions on before commiting.

= http://bugzilla.gnome.org/show_bug.cgi?id=383456
anyone a better idea how to call gtkdoc-check for the tests (that avoids copying)

= http://bugzilla.gnome.org/show_bug.cgi?id=338068
please test the tmpl-free build

= http://bugzilla.gnome.org/show_bug.cgi?id=156643
please comment

Thanks!

Stefan
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

Hi,
Stefan Kost wrote:

> hi,
>
> there is some stuff that I would like to get second opinions on before commiting.
>
> = http://bugzilla.gnome.org/show_bug.cgi?id=383456
> anyone a better idea how to call gtkdoc-check for the tests (that avoids copying)
>
> = http://bugzilla.gnome.org/show_bug.cgi?id=338068
> please test the tmpl-free build
>
> = http://bugzilla.gnome.org/show_bug.cgi?id=156643
> please comment
>

I'll continue some generic discussion here.

= gtkdocize
I'll add a option "--flavour' to select which gtkdoc.mak to use. Flavours can be:
- legacy : the current gtkdoc.mak + the dummy rule as agreed in
  http://bugzilla.gnome.org/show_bug.cgi?id=156643
- modern : the template free version from
  http://bugzilla.gnome.org/show_bug.cgi?id=338068

Regarding the latter, Yeti mentioned that we should try to radically get rid of
more cruft. If that involves more steps, should I name 'modern' 'modern-1.9' to
allow even more modern versions? Regarding the copying should I add '--force'
like in the other *ize bootstrap scripts to force overwriting the gtkdoc.mak
(even though it changes behaviour as it is overwriting by default now).

= .types file
gtkdoc-scan with --rebuild-types can recreate a types file. Problems:
* contains also the _get_types for enums (I belive gtkdoc-scanobj is now smart
enough to not introspect those).
* projects should use --ignore-headers to skip disabled modules.
* it misses the #includes - are they needed

= sections.txt file
The *-decl-list.txt should mabe be sorted so that it easier to see whats the
difference of the mainually managed one.
It does not list everything (e.g. XXXClass)

Stefan

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

hi again,

> = .types file
> gtkdoc-scan with --rebuild-types can recreate a types file. Problems:
> * contains also the _get_types for enums (I belive gtkdoc-scanobj is now smart
> enough to not introspect those).
> * projects should use --ignore-headers to skip disabled modules.
> * it misses the #includes - are they needed ?

yes, they are:

bt-core-scan.c: In function 'main':
bt-core-scan.c:134: warning: implicit declaration of function 'gst_init'
Compilation of scanner failed:

I reopened
http://bugzilla.gnome.org/show_bug.cgi?id=338517

Stefan
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Fri, Aug 10, 2007 at 08:30:09PM +0300, Stefan Kost wrote:

> > = .types file
> > gtkdoc-scan with --rebuild-types can recreate a types file. Problems:
> > * contains also the _get_types for enums (I belive gtkdoc-scanobj is now smart
> > enough to not introspect those).
> > * projects should use --ignore-headers to skip disabled modules.
> > * it misses the #includes - are they needed ?
>
> yes, they are:
>
> bt-core-scan.c: In function 'main':
> bt-core-scan.c:134: warning: implicit declaration of function 'gst_init'
> Compilation of scanner failed:

gst_init() is not a get_type() function, how it got there?

If the package needs to execute some other code for the
get_type() functions to work, then yes, auto-generated types
cannot be used.  More precisely, they can be used if one can
specify the startup code somewhere.  But I'm afraid this
gets us into an area where people may want so disparate and
weird things that assuming they will customize gtk-doc.make
anyway is a safe bet...

It seems you cannot reasonably use --rebuild-types, so is
this still about (not) putting this option into the stock
(modern) makefile or am I completely lost?

Note I'm fine with --rebuild-types not present in the stock
makefile, but things (cleaning, making dists, dependencies)
must not break when one adds

SCAN_OPTIONS = --rebuild-types

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Fri, Aug 10, 2007 at 07:46:21PM +0200, David Nečas (Yeti) wrote:
>
> It seems you cannot reasonably use --rebuild-types

Sorry, you can.  See
http://bugzilla.gnome.org/show_bug.cgi?id=338517#c9

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

Hi,

David Nečas (Yeti) wrote:

> On Fri, Aug 10, 2007 at 08:30:09PM +0300, Stefan Kost wrote:
>>> = .types file
>>> gtkdoc-scan with --rebuild-types can recreate a types file. Problems:
>>> * contains also the _get_types for enums (I belive gtkdoc-scanobj is now smart
>>> enough to not introspect those).
>>> * projects should use --ignore-headers to skip disabled modules.
>>> * it misses the #includes - are they needed ?
>> yes, they are:
>>
>> bt-core-scan.c: In function 'main':
>> bt-core-scan.c:134: warning: implicit declaration of function 'gst_init'
>> Compilation of scanner failed:
>
> gst_init() is not a get_type() function, how it got there?
>
> If the package needs to execute some other code for the
> get_type() functions to work, then yes, auto-generated types
> cannot be used.  More precisely, they can be used if one can
> specify the startup code somewhere.  But I'm afraid this
> gets us into an area where people may want so disparate and
> weird things that assuming they will customize gtk-doc.make
> anyway is a safe bet...

The issue is that probably lots of libs need to call some foreign init. If I
e.g. don't do that for gst_init (gstreamer) that all my gstreamer subclassed
types would show up as gobjects.

Stefan
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Fri, Aug 10, 2007 at 10:03:05PM +0300, Stefan Kost wrote:
>
> The issue is that probably lots of libs need to call some foreign init. If I
> e.g. don't do that for gst_init (gstreamer) that all my gstreamer subclassed
> types would show up as gobjects.

I think we found a way to get the code there, although it
is a bit ugly.

However, I am still curious why automatic parent type
registration and resolution does not work for you. Try the
attached program (it does not call gst_init() or anything)
and tell me where it gets the types wrong -- or explain what
`would show up as gobjects' means, they are GObject based,
aren't they?

(It prints a thread-initialization error, but that's another
matter.)

Yeti

--
http://gwyddion.net/


=====[ Makefile ]=======================================================
DEPS = gstreamer-base-0.10 gstreamer-net-0.10 gstreamer-controller-0.10 gstreamer-dataprotocol-0.10 gmodule-2.0
LIBTOOL = libtool --tag=CC
PKG_CONFIG = pkg-config
CC = gcc
CFLAGS := -Wall -W -O -ggdb $(shell $(PKG_CONFIG) --cflags $(DEPS))
LDFLAGS := $(shell $(PKG_CONFIG) --libs $(DEPS))

gsttypes: gsttypes.c
        $(LIBTOOL) --mode=compile $(CC) $(CFLAGS) -c -o gsttypes.o gsttypes.c
        $(LIBTOOL) --mode=link $(CC) $(LDFLAGS) -export-dynamic -o gsttypes gsttypes.o

clean:
        rm -f gsttypes gsttypes.o gsttypes.lo
        rm -rf .libs
=====[ gsttypes.c ]=====================================================
#include <stdlib.h>
#include <gmodule.h>
#include <glib-object.h>

static const char *typenames[] = {
    "activate_mode", "adapter", "alloc_trace_flags", "assoc_flags",
    "base_sink", "base_src", "base_transform", "bin_flags", "bin",
    "buffer_flag", "buffer", "bus_flags", "bus", "bus_sync_reply",
    "caps_flags", "caps", "child_proxy", "clock_entry_type", "clock_flags",
    "clock", "clock_return", "collect_pads", "controller", "core_error",
    "data_queue", "date", "debug_color_flags", "debug_level", "double_range",
    "dp_version", "element_factory", "element_flags", "element", "event",
    "event_type_flags", "event_type", "flow_return", "format", "fourcc",
    "fraction", "fraction_range", "g_error", "ghost_pad",
    "implements_interface", "index_certainty", "index_entry",
    "index_entry_type", "index_factory", "index_flags", "index",
    "index_lookup_method", "index_resolver_method", "int_range",
    "iterator_item", "iterator_result", "library_error", "message",
    "message_type", "mini_object_flags", "mini_object", "net_client_clock",
    "net_time_provider", "object_flags", "object", "pad_direction",
    "pad_flags", "pad", "pad_link_return", "pad_presence",
    "pad_template_flags", "pad_template", "parse_error", "pipeline_flags",
    "pipeline", "plugin_error", "plugin_feature", "plugin_flags", "plugin",
    "push_src", "query", "query_type", "rank", "registry", "resource_error",
    "seek_flags", "seek_type", "segment", "state_change",
    "state_change_return", "state", "static_caps", "static_pad_template",
    "stream_error", "structure", "system_clock", "tag_flag", "tag_list",
    "tag_merge_mode", "tag_setter", "task", "task_state", "type_find_factory",
    "type_find", "type_find_probability", "uri_handler", "uri_type",
    "value_array", "value_list", "xml",
};

typedef GType (*TypeRegistrar)(void);

static void
dump_type(GType type)
{
    guint i, j, nids, *ids;

    i = 0;
    do {
        g_print("%s%s", i ? " -> " : "", g_type_name(type));
        if (!i && (G_TYPE_IS_INSTANTIATABLE(type)
                   || G_TYPE_IS_INTERFACE(type))) {
            ids = g_signal_list_ids(type, &nids);
            for (j = 0; j < nids; j++) {
                g_print("[%s]", g_signal_name(ids[j]));
            }
            g_free(ids);
        }
        i++;
    } while ((type = g_type_parent(type)));
    g_print("\n");
}

int
main(void)
{
    TypeRegistrar typefunc;
    GString *symbolstr;
    GType type;
    GModule *handle;
    GArray *types;
    guint i;

    g_type_init();

    handle = g_module_open(NULL, G_MODULE_BIND_LAZY);
    if (!handle) {
        g_printerr("Cannot open self: %s\n", g_module_error());
        return EXIT_FAILURE;
    }

    symbolstr = g_string_new(NULL);
    types = g_array_new(FALSE, FALSE, sizeof(GType));
    for (i = 0; i < G_N_ELEMENTS(typenames); i++) {
        g_string_assign(symbolstr, "gst_");
        g_string_append(symbolstr, typenames[i]);
        g_string_append(symbolstr, "_get_type");
        if (!g_module_symbol(handle, symbolstr->str, (gpointer*)&typefunc)) {
            g_printerr("Cannot get %s: %s\n", symbolstr->str, g_module_error());
            continue;
        }
        type = typefunc();
        if (!type) {
            g_printerr("%s returns 0\n", symbolstr->str);
            continue;
        }
        g_array_append_val(types, type);
        if (G_TYPE_IS_CLASSED(type))
            g_type_class_ref(type);
        if (G_TYPE_IS_INTERFACE(type))
            g_type_default_interface_ref(type);
    }
    g_string_free(symbolstr, TRUE);

    g_print("==== INSTANTIABLE ====\n");
    for (i = 0; i < types->len; i++) {
        type = g_array_index(types, GType, i);
        if (G_TYPE_IS_INSTANTIATABLE(type) && !G_TYPE_IS_ABSTRACT(type))
            dump_type(type);
    }
    g_print("==== ABSTRACT ====\n");
    for (i = 0; i < types->len; i++) {
        type = g_array_index(types, GType, i);
        if (G_TYPE_IS_INSTANTIATABLE(type) && G_TYPE_IS_ABSTRACT(type))
            dump_type(type);
    }
    g_print("==== INTERFACES ====\n");
    for (i = 0; i < types->len; i++) {
        type = g_array_index(types, GType, i);
        if (G_TYPE_IS_INTERFACE(type))
            dump_type(type);
    }
    g_print("==== SIMPLE ====\n");
    for (i = 0; i < types->len; i++) {
        type = g_array_index(types, GType, i);
        if (!G_TYPE_IS_INTERFACE(type) && !G_TYPE_IS_INSTANTIATABLE(type)
            && g_type_parent(type))
            dump_type(type);
    }
    g_print("==== FUNDAMENTAL ====\n");
    for (i = 0; i < types->len; i++) {
        type = g_array_index(types, GType, i);
        if (!G_TYPE_IS_INTERFACE(type) && !G_TYPE_IS_INSTANTIATABLE(type)
            && !g_type_parent(type)) {
            g_assert(G_TYPE_IS_FUNDAMENTAL(type));
            dump_type(type);
        }
    }

    g_array_free(types, TRUE);
    g_module_close(handle);

    return 0;
}
========================================================================
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

David Nečas (Yeti) wrote:

> On Fri, Aug 10, 2007 at 10:03:05PM +0300, Stefan Kost wrote:
>> The issue is that probably lots of libs need to call some foreign init. If I
>> e.g. don't do that for gst_init (gstreamer) that all my gstreamer subclassed
>> types would show up as gobjects.
>
> I think we found a way to get the code there, although it
> is a bit ugly.
>
> However, I am still curious why automatic parent type
> registration and resolution does not work for you. Try the
> attached program (it does not call gst_init() or anything)
> and tell me where it gets the types wrong -- or explain what
> `would show up as gobjects' means, they are GObject based,
> aren't they?
>
> (It prints a thread-initialization error, but that's another
> matter.)
>
> Yeti
>

Here it is (ignome the gst_xml_get_type as I have a xml free gstreamer). And I
tried again this morning and with fresh eayes I saw that it worked, but becauses
the types are not alphabetically sorted I missed it. I would like to change it
so that it sorts the generated types (and also the generated sections file).

Stefan

> ./gsttypes

(process:14880): GLib-CRITICAL **: g_thread_pool_new: assertion
`g_thread_supported ()' failed
Cannot get gst_xml_get_type: `gst_xml_get_type': ./gsttypes: undefined symbol:
gst_xml_get_type
==== INSTANTIABLE ====
GstAdapter -> GObject
GstBin[element-added][element-removed] -> GstElement -> GstObject -> GObject
GstBuffer -> GstMiniObject
GstBus[sync-message][message] -> GstObject -> GObject
GstCollectPads -> GstObject -> GObject
GstController -> GObject
GstDataQueue[empty][full] -> GObject
GstElementFactory -> GstPluginFeature -> GstObject -> GObject
GstEvent -> GstMiniObject
GstGhostPad -> GstProxyPad -> GstPad -> GstObject -> GObject
GstIndexFactory -> GstPluginFeature -> GstObject -> GObject
GstIndex[entry-added] -> GstObject -> GObject
GstMessage -> GstMiniObject
GstNetClientClock -> GstSystemClock -> GstClock -> GstObject -> GObject
GstNetTimeProvider -> GstObject -> GObject
GstPad[linked][unlinked][request-link][have-data] -> GstObject -> GObject
GstPadTemplate[pad-created] -> GstObject -> GObject
GstPipeline -> GstBin -> GstElement -> GstObject -> GObject
GstPlugin -> GstObject -> GObject
GstPushSrc -> GstBaseSrc -> GstElement -> GstObject -> GObject
GstQuery -> GstMiniObject
GstRegistry[plugin-added][feature-added] -> GstObject -> GObject
GstSystemClock -> GstClock -> GstObject -> GObject
GstTask -> GstObject -> GObject
GstTypeFindFactory -> GstPluginFeature -> GstObject -> GObject
==== ABSTRACT ====
GstBaseSink -> GstElement -> GstObject -> GObject
GstBaseSrc -> GstElement -> GstObject -> GObject
GstBaseTransform -> GstElement -> GstObject -> GObject
GstClock -> GstObject -> GObject
GstElement[pad-added][pad-removed][no-more-pads] -> GstObject -> GObject
GstMiniObject
GstObject[parent-set][parent-unset][deep-notify] -> GObject
GstPluginFeature -> GstObject -> GObject
==== INTERFACES ====
GstChildProxy[child-added][child-removed] -> GInterface
GstImplementsInterface -> GInterface
GstTagSetter -> GInterface
GstURIHandler[new-uri] -> GInterface
==== SIMPLE ====
GstActivateMode -> GEnum
GstAllocTraceFlags -> GFlags
GstAssocFlags -> GFlags
GstBinFlags -> GFlags
GstBufferFlag -> GFlags
GstBusFlags -> GFlags
GstBusSyncReply -> GEnum
GstCapsFlags -> GFlags
GstCaps -> GBoxed
GstClockEntryType -> GEnum
GstClockFlags -> GFlags
GstClockReturn -> GEnum
GstCoreError -> GEnum
GstDate -> GBoxed
GstDebugColorFlags -> GEnum
GstDebugLevel -> GEnum
GstDPVersion -> GEnum
GstElementFlags -> GFlags
GstEventTypeFlags -> GFlags
GstEventType -> GEnum
GstFlowReturn -> GEnum
GstFormat -> GEnum
GstGError -> GBoxed
GstIndexCertainty -> GEnum
GstIndexEntry -> GBoxed
GstIndexEntryType -> GEnum
GstIndexFlags -> GFlags
GstIndexLookupMethod -> GEnum
GstIndexResolverMethod -> GEnum
GstIteratorItem -> GEnum
GstIteratorResult -> GEnum
GstLibraryError -> GEnum
GstMessageType -> GFlags
GstMiniObjectFlags -> GFlags
GstObjectFlags -> GFlags
GstPadDirection -> GEnum
GstPadFlags -> GFlags
GstPadLinkReturn -> GEnum
GstPadPresence -> GEnum
GstPadTemplateFlags -> GFlags
GstParseError -> GEnum
GstPipelineFlags -> GFlags
GstPluginError -> GEnum
GstPluginFlags -> GFlags
GstQueryType -> GEnum
GstRank -> GEnum
GstResourceError -> GEnum
GstSeekFlags -> GFlags
GstSeekType -> GEnum
GstSegment -> GBoxed
GstStateChange -> GEnum
GstStateChangeReturn -> GEnum
GstState -> GEnum
GstStaticCaps -> gpointer
GstStaticPadTemplate -> gpointer
GstStreamError -> GEnum
GstStructure -> GBoxed
GstTagFlag -> GEnum
GstTagList -> GBoxed
GstTagMergeMode -> GEnum
GstTaskState -> GEnum
GstTypeFind -> gpointer
GstTypeFindProbability -> GEnum
GstURIType -> GEnum
==== FUNDAMENTAL ====
GstDoubleRange
GstFourcc
GstFraction
GstFractionRange
GstIntRange
GstValueArray
GstValueList
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

David,

I belive a have a fix for the tmpl build (3 lines). I'll commit it in a minute.
I would also like to commit the gtkdoc.modern.make, so that we can work on it.
Is that okay with you?

What do you think about the gtkdocize issues?
* should I add a --force option?
* what about the flavour naming?

Stefan

Stefan Kost wrote:

> Hi,
> Stefan Kost wrote:
>> hi,
>>
>> there is some stuff that I would like to get second opinions on before commiting.
>>
>> = http://bugzilla.gnome.org/show_bug.cgi?id=383456
>> anyone a better idea how to call gtkdoc-check for the tests (that avoids copying)
>>
>> = http://bugzilla.gnome.org/show_bug.cgi?id=338068
>> please test the tmpl-free build
>>
>> = http://bugzilla.gnome.org/show_bug.cgi?id=156643
>> please comment
>>
>
> I'll continue some generic discussion here.
>
> = gtkdocize
> I'll add a option "--flavour' to select which gtkdoc.mak to use. Flavours can be:
> - legacy : the current gtkdoc.mak + the dummy rule as agreed in
>   http://bugzilla.gnome.org/show_bug.cgi?id=156643
> - modern : the template free version from
>   http://bugzilla.gnome.org/show_bug.cgi?id=338068
>
> Regarding the latter, Yeti mentioned that we should try to radically get rid of
> more cruft. If that involves more steps, should I name 'modern' 'modern-1.9' to
> allow even more modern versions? Regarding the copying should I add '--force'
> like in the other *ize bootstrap scripts to force overwriting the gtkdoc.mak
> (even though it changes behaviour as it is overwriting by default now).
>
> = .types file
> gtkdoc-scan with --rebuild-types can recreate a types file. Problems:
> * contains also the _get_types for enums (I belive gtkdoc-scanobj is now smart
> enough to not introspect those).
> * projects should use --ignore-headers to skip disabled modules.
> * it misses the #includes - are they needed
>
> = sections.txt file
> The *-decl-list.txt should mabe be sorted so that it easier to see whats the
> difference of the mainually managed one.
> It does not list everything (e.g. XXXClass)
>
> Stefan
>

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Sat, Aug 11, 2007 at 12:41:14PM +0300, Stefan Kost wrote:
> I belive a have a fix for the tmpl build (3 lines). I'll commit it in a minute.
> I would also like to commit the gtkdoc.modern.make, so that we can work on it.
> Is that okay with you?

Ok.

Please also apply simple fixes such as
http://bugzilla.gnome.org/show_bug.cgi?id=459225

> What do you think about the gtkdocize issues?
> * should I add a --force option?

Can't judge, I'm not a big fan of these (I even use an ugly
hack in my autogen to steal files from gettextize without
actually running it...).

> * what about the flavour naming?

According to the main change it brings.

You need a new flavour only if you substantially change the
style and mode of operation.  If the result cannot be
described with a catchy phrase, it does not worth the
work...  So I would call the new one `notmpl' or something
like that (I would prefer if it also included bulding in
builddir, but that's something notmpl makes possible so the
name still fits).

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

Hi,

David Nečas (Yeti) wrote:
> On Sat, Aug 11, 2007 at 12:41:14PM +0300, Stefan Kost wrote:
>> I belive a have a fix for the tmpl build (3 lines). I'll commit it in a minute.
>> I would also like to commit the gtkdoc.modern.make, so that we can work on it.
>> Is that okay with you?
>
> Ok.
>
> Please also apply simple fixes such as
> http://bugzilla.gnome.org/show_bug.cgi?id=459225

done.

>
>> What do you think about the gtkdocize issues?
>> * should I add a --force option?
>
> Can't judge, I'm not a big fan of these (I even use an ugly
> hack in my autogen to steal files from gettextize without
> actually running it...).
>
>> * what about the flavour naming?
>
> According to the main change it brings.
>
> You need a new flavour only if you substantially change the
> style and mode of operation.  If the result cannot be
> described with a catchy phrase, it does not worth the
> work...  So I would call the new one `notmpl' or something
> like that (I would prefer if it also included bulding in
> builddir, but that's something notmpl makes possible so the
> name still fits).

Also done. Will commit after a bit of testing. I would also like to bump the
version. What about bumping the version immediately after a release. So I would
bump it to 1.9 now and after its released to 1.10. Okay?

Stefan

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

Hi David,

could reply and mention the issues you would like to get fixed/handle for 1.9. I
have some cleanup planned (sorting types and -dect.txt) and I work on a
gtkdoc-tmpl2src tool (uninstalled by default) to aid getting legacy docs (e.g.
gtk/glib) from the tmpl files into the source files.

Regarding http://bugzilla.gnome.org/show_bug.cgi?id=338068#c4
* we could stop disting .types file only if projects requite gtkdoc-1.8 and use
--rebuild-types in their SCAN_OPTIONS. Any idea how to improve the makefile
logic to figure out?

* I agree with not disting the xml files. patches welcome

* Getting rid of "@-chmod -R u+w $(srcdir)". Is this
http://bugzilla.gnome.org/show_bug.cgi?id=460753 ?

Regarding http://bugzilla.gnome.org/show_bug.cgi?id=338068#c6
* If you have an idea how, lets fix it.


Stefan
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Mon, Aug 13, 2007 at 11:25:01PM +0300, Stefan Kost wrote:
>
> Regarding http://bugzilla.gnome.org/show_bug.cgi?id=338068#c4
> * we could stop disting .types file only if projects requite gtkdoc-1.8 and use
> --rebuild-types in their SCAN_OPTIONS. Any idea how to improve the makefile
> logic to figure out?

I would just

  echo x$(SCAN_OPTIONS) | grep '^x.*--rebuild-types'

in dist and clean hooks to check whether the option is
present.  The same for sections.  The `x' is there to avoid
passing something that starts with `-' to echo and grep,
they could react unpredictably -- cleaner suggestions
welcome.

> * I agree with not disting the xml files. patches welcome

They will flow...

Beside content XMLs, the only files you need to distribute
are
- the driver document
- overrides
- sections (unless --rebuild-sections is used)
- types (unless --rebuild-types is used)

> * Getting rid of "@-chmod -R u+w $(srcdir)". Is this
> http://bugzilla.gnome.org/show_bug.cgi?id=460753 ?

This is just a small (although necessary) part of it.
The main bug is the old here:

  http://bugzilla.gnome.org/show_bug.cgi?id=127049

and the main patch is the addition of --master-dir=DIR
option to all relevant tools.  In the modern makefile, they
will get --master-dir=$(srcdir) and they will look for files
in the build directory or (failing that) in the master
directory.

Old-style makefiles will behave as before, which means VPATH
builds not really working.

> Regarding http://bugzilla.gnome.org/show_bug.cgi?id=338068#c6
> * If you have an idea how, lets fix it.

This will be fixed automatically when we start building in
builddir.  All files are created in builddir then (well,
with a few exceptions, for instance the initial driver
document will be created in the master directory -- if I got
it right the tools are smart enough to know whether you want
for instance the section file in builddir or srcdir, anyway,
I do not expect people to use VPATH builds for bootstrapping).

Note none of the bugs contain gtk-doc.make patches,
I prefer to first add the capability to the tools
(~mechanism), then, possibly, change the default makefile
(~policy).

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list