Nabble - Gtk+ - Documentation

ANNOUNCE: gtk-doc 1.10

2008-03-19T13:47:54Z

GTK-Doc 1.10 (Mar 20 2008)
============

Changes

o 460753 : enable vpath build in gtkdoc-mkhtml
o 503119 : Add dependency on content_files to SGML target
o 127049 : building reference documentation fails when builddir != s...
o 481811 : Inline function bodies are confused with declarations
o 448879 : Use a footer when generating HTML documentation
o 492005 : Deprecation guard warnings for properties and signals
o 498521 : Inconsistent compiler flags passed in gtk-doc.make
o 365913 : gtk-doc output is not predictable
o 446648 : gtk-doc does not handle forward typedef'd enums
o 468278 : Display proper types for properties
o 497367 : don't use US-ASCII for output encoding
o 501066 : Missing quotes around gtkdoc-rebase check cause a warning
o 508897 : [PATCH] Fix build when gtk-doc is not installed
o 509539 : Building documentation aborts when no .types file is present
o 512154 : Struct member type attributes are limited to one token
o 513318 : gtk-doc.el doesn't work fine with emacs22

Contributors

Benjamin Otte
Carlos Garnacho
Damon Chaplin
David Nečas
Frederic Peters
Joe Marcus Clarke
Kouhei Sutou
Loïc Minier
Mathias Hasselmann
Petteri Räty
Rouslan Solomakhin
Stefan Kost
Sven Herzberg
Yeti
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

SVN frozen for one day

2008-03-19T13:45:53Z

hi,

lets keep svn frozen for a day or two. I'll commit the release marker in the
changelog and bump versions, if the release is okay.

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

Re: problems with deprecation of struct members

2007-12-04T15:21:33Z

On Dec 4, 2007 3:57 PM, Stefan Kost <ensonic@...> wrote:
> Hi again,
>
> it was just a simple bugs. Altest building the docs should be fine now. If you
> have a good idea how to display this in a smarter way, please let me know.

Thanks, it did indeed produce complete gtk docs this time.
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

Re: problems with deprecation of struct members

2007-12-04T12:57:28Z

Hi again,

it was just a simple bugs. Altest building the docs should be fine now. If you
have a good idea how to display this in a smarter way, please let me know.

Stefan

Matthias Clasen schrieb:

> I am having issues getting gtk-doc 1.9 to produce complete gtk+ docs for me.
> The 2.12.2 release I did yesterday contains a pretty incomplete set of gtk docs,
> unfortunately.
>
> The issue seems to be this field in the _GtkToolbar struct:
>
>
> #ifndef GTK_DISABLE_DEPRECATED
> GtkTooltips *tooltips;
> #else
> gpointer _tooltips;
> #endif
>
>
> When I have that in the headers, I get the following from gtkdoc-scan:
>
> Cannot parse structure field "}" in struct _GtkToolbar
>
> After patching the message to dump out the whole $declaration as well,
> I get:
>
> {
> gint num_children;
> GList *children;
> GtkOrientation orientation;
> GtkToolbarStyle style;
> GtkIconSize icon_size;
>
> #ifndef GTK_DISABLE_DEPRECATED
> GtkTooltips *tooltips;
> #else
> gpointer _tooltips;
> #endif
> };
>
>
> Notice how it thinks the struct ends after the ifdef, when in fact it doesn't.
>
> I first thought this was due to the #else, but when I replace it with
>
> #ifndef GTK_DISABLE_DEPRECATED
> GtkTooltips *tooltips;
> #endif
>
> I still get the same error.
>
> I'd like to build a 2.12.3 with complete docs, but I need to have a gtk-doc fix
> before I can do so....
>
>
> Matthias
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-doc-list

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

Re: problems with deprecation of struct members

2007-12-03T11:47:51Z

Hi,

Matthias Clasen schrieb:

Hmm, this is not easy to fix. The parse is not smart enough to allow deprecating
single parts (like arguments in a function). I'll try very hard to have a
gtk-doc day this week and then I see if it can be handled. Practically gtk-doc
would need some special casing for this, as in the docs we just would like to
show some grayed
GtkTooltips *tooltips; /* deprecated */
and not an #ifdef ... #endif

Stefan

>
>
> When I have that in the headers, I get the following from gtkdoc-scan:
>
> Cannot parse structure field "}" in struct _GtkToolbar
>
> After patching the message to dump out the whole $declaration as well,
> I get:
>
> {
> gint num_children;
> GList *children;
> GtkOrientation orientation;
> GtkToolbarStyle style;
> GtkIconSize icon_size;
>
> #ifndef GTK_DISABLE_DEPRECATED
> GtkTooltips *tooltips;
> #else
> gpointer _tooltips;
> #endif
> };
>
>
> Notice how it thinks the struct ends after the ifdef, when in fact it doesn't.
>
> I first thought this was due to the #else, but when I replace it with
>
> #ifndef GTK_DISABLE_DEPRECATED
> GtkTooltips *tooltips;
> #endif
>
> I still get the same error.
>
> I'd like to build a 2.12.3 with complete docs, but I need to have a gtk-doc fix
> before I can do so....
>
>
> Matthias
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-doc-list

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

problems with deprecation of struct members

2007-11-27T10:01:02Z

I am having issues getting gtk-doc 1.9 to produce complete gtk+ docs for me.
The 2.12.2 release I did yesterday contains a pretty incomplete set of gtk docs,
unfortunately.

The issue seems to be this field in the _GtkToolbar struct:

#ifndef GTK_DISABLE_DEPRECATED
GtkTooltips *tooltips;
#else
gpointer _tooltips;
#endif

When I have that in the headers, I get the following from gtkdoc-scan:

Cannot parse structure field "}" in struct _GtkToolbar

After patching the message to dump out the whole $declaration as well,
I get:

{
gint num_children;
GList *children;
GtkOrientation orientation;
GtkToolbarStyle style;
GtkIconSize icon_size;

#ifndef GTK_DISABLE_DEPRECATED
GtkTooltips *tooltips;
#else
gpointer _tooltips;
#endif
};

Notice how it thinks the struct ends after the ifdef, when in fact it doesn't.

I first thought this was due to the #else, but when I replace it with

#ifndef GTK_DISABLE_DEPRECATED
GtkTooltips *tooltips;
#endif

I still get the same error.

I'd like to build a 2.12.3 with complete docs, but I need to have a gtk-doc fix
before I can do so....

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

Re: docbook DTD version

2007-10-31T07:33:01Z

On Wed, Oct 31, 2007 at 01:59:50PM +0100, Stefan Kost wrote:
> we got this rfe filed for gtk-doc to sync the required dtd version
> with gnome-doc-utils:
> http://bugzilla.gnome.org/show_bug.cgi?id=487727
>
> I experimented a bit and basically I see n issue with using 4.3 too.
> We could also lazyly accept any DTD in a certain version range. Any
> ideas whats the best strategy here?

Read DTD from $(DOC_MAIN_SGML_FILE). Generate files with
this DTD (after some basic sanity check). This way the user
can use any compatible DTD he wishes.

However, this shifts the responsibility of checking for the
right DTD from gtk-doc to the application (not a bad thing
in principle IMO, though gtk-doc.m4 should provide means to
add such check easily). However, it does not lift the
requirement of some default version by gtk-doc itself.

Yeti

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

docbook DTD version

2007-10-31T06:59:50Z

hi,

we got this rfe filed for gtk-doc to sync the required dtd version
with gnome-doc-utils:
http://bugzilla.gnome.org/show_bug.cgi?id=487727

I experimented a bit and basically I see n issue with using 4.3 too.
We could also lazyly accept any DTD in a certain version range. Any
ideas whats the best strategy here?

Stefan

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

Re: how to guard deprecated signals

2007-10-31T06:56:05Z

Hi,
Quoting "David Ne?as (Yeti)" <yeti@...>:

> On Tue, Oct 30, 2007 at 10:23:59PM +0200, Stefan Kost wrote:
>> just found a property in gstreamer that is deprecated. Thus I get
>> this from gtk-doc:
>>
>> WARNING: GstBaseRTPDepayload::queue-delay is deprecated in the
>> inline comments
>> but no deprecation guards were found around the declaration.
>> (See the --deprecated-guards option for gtkdoc-scan.)
>>
>> Now I wonder where one should/could add deprecation guards?
>> #ifndef GST_DISABLE_DEPRECATED
>> #endif
>>
>> gtk-doc expects them in the headers.
>
> The warning is wrong. First, I think marking deprecated
> symbols with preprocessor conditionals in the header files
> is a matter of coding style of a particular project and
> should not be mandatory.
>
> But more to the point, it is impossible to make something
> inaccessible with an #ifdef when it's registered run-time by
> the library (which, of course, has a completely different
> idea of what is deprecated and what is not than the library
> version you compiled the app with, and madness lies in the
> direction of run-time deprecation handling as deprecation is
> nothing else than a weak form of backward compatibility
> breach).
>
> So, for signals and properties, you have to trust the
> documentation and not emit such warnings.

Right. Fixed in SVN

Stefan

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

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

Re: how to guard deprecated signals

2007-10-30T16:42:12Z

On Tue, Oct 30, 2007 at 10:23:59PM +0200, Stefan Kost wrote:

> just found a property in gstreamer that is deprecated. Thus I get this from gtk-doc:
>
> WARNING: GstBaseRTPDepayload::queue-delay is deprecated in the inline comments
> but no deprecation guards were found around the declaration.
> (See the --deprecated-guards option for gtkdoc-scan.)
>
> Now I wonder where one should/could add deprecation guards?
> #ifndef GST_DISABLE_DEPRECATED
> #endif
>
> gtk-doc expects them in the headers.

The warning is wrong. First, I think marking deprecated
symbols with preprocessor conditionals in the header files
is a matter of coding style of a particular project and
should not be mandatory.

But more to the point, it is impossible to make something
inaccessible with an #ifdef when it's registered run-time by
the library (which, of course, has a completely different
idea of what is deprecated and what is not than the library
version you compiled the app with, and madness lies in the
direction of run-time deprecation handling as deprecation is
nothing else than a weak form of backward compatibility
breach).

So, for signals and properties, you have to trust the
documentation and not emit such warnings.

Yeti

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

how to guard deprecated signals

2007-10-30T14:23:59Z

hi,

just found a property in gstreamer that is deprecated. Thus I get this from gtk-doc:

WARNING: GstBaseRTPDepayload::queue-delay is deprecated in the inline comments
but no deprecation guards were found around the declaration.
(See the --deprecated-guards option for gtkdoc-scan.)

Now I wonder where one should/could add deprecation guards?
#ifndef GST_DISABLE_DEPRECATED
#endif

gtk-doc expects them in the headers.

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

Re: gtk-doc 1.9 issues

2007-10-22T07:26:05Z

Hi,
Quoting "David Ne?as (Yeti)" <yeti@...>:

> On Mon, Oct 15, 2007 at 07:56:01PM -0400, Matthias Clasen wrote:
>> I just tried to push 1.9 into Fedora, but it didn't work out, since
>> make install installs the docs into /usr/share/doc/gtk-doc/, not
>> /usr/share/gnome/help, where they belong.
>>
>> I do remember fixing the same bug in the past, but the fix seems to
>> have been reverted...
>
> The culprit is
>
> http://svn.gnome.org/viewvc/gtk-doc/trunk/xmldocs.make?r1=388&r2=413
>
> which changed the installations directories from $(gtkdochelpdir)
> to $(docdir).
>
> However, the new version matches exactly the current
> gnome-common's of xmldocs.make:
>
>
> http://svn.gnome.org/viewvc/gnome-common/trunk/doc-build/xmldocs.make?revision=3486&view=markup
>
> So, whose mistake it is? And this is not a rhetorical
> question, I can tell what some code does, but not what it
> was supposed to do.
>
> docdir is set to the correct value in the Makefile snippet
>
> docdir = $(datadir)/gnome/help/$(docname)/$(lang)
>
> and if some packaging magic overrides docdir...
>
> Yeti
>

when I run autoregen.sh I get:

xmldocs.make:39: docdir was already defined in condition TRUE, which
includes condition ENABLE_SCROLLKEEPER ...
help/manual/C/Makefile.am:8: `xmldocs.make' included from here
configure.in:8: ... `docdir' previously defined here

btw. its:
http://bugzilla.gnome.org/show_bug.cgi?id=316508

the upstream version has not seen many changes too
http://svn.gnome.org/viewvc/gnome-common/trunk/doc-build/xmldocs.make?revision=3486&view=markup

I wrote an email to gnome-doc list and if nothing happens, file a bug
against gnome-common.

Stefan

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

Re: gtk-doc 1.9 issues

2007-10-17T08:12:53Z

On Mon, Oct 15, 2007 at 07:56:01PM -0400, Matthias Clasen wrote:
> I just tried to push 1.9 into Fedora, but it didn't work out, since
> make install installs the docs into /usr/share/doc/gtk-doc/, not
> /usr/share/gnome/help, where they belong.
>
> I do remember fixing the same bug in the past, but the fix seems to
> have been reverted...

The culprit is

http://svn.gnome.org/viewvc/gtk-doc/trunk/xmldocs.make?r1=388&r2=413

which changed the installations directories from $(gtkdochelpdir)
to $(docdir).

However, the new version matches exactly the current
gnome-common's of xmldocs.make:

http://svn.gnome.org/viewvc/gnome-common/trunk/doc-build/xmldocs.make?revision=3486&view=markup

So, whose mistake it is? And this is not a rhetorical
question, I can tell what some code does, but not what it
was supposed to do.

docdir is set to the correct value in the Makefile snippet

docdir = $(datadir)/gnome/help/$(docname)/$(lang)

and if some packaging magic overrides docdir...

Yeti

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

gtk-doc 1.9 issues

2007-10-15T17:56:01Z

I just tried to push 1.9 into Fedora, but it didn't work out, since
make install installs the docs into /usr/share/doc/gtk-doc/, not
/usr/share/gnome/help, where they belong.

I do remember fixing the same bug in the past, but the fix seems to
have been reverted...
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

ANNOUNCE: gtk-doc 1.9

2007-09-30T11:36:28Z

Application
===========

gtk-doc 1.9

Description
===========

gtk-doc is used to document the API of the GTK+ and GNOME libraries.

GTK-Doc 1.9 (Sep 30 2007)
===========

Changes

o 419308 : unsynced regexps for parameter parsing
o 449618 : Top navigation bar is in the way
o 453717 : fixxref logic to determine absolute path's is flawed
o 457173 : unit tests for gtk-doc
o 465920 : Use gtkdoc-rebase
o 467773 : default master doc should have proper extension
o 141869 : Poor error generated when faced with a type declared as '...
o 156643 : Avoid make error in gtk-doc.make
o 322035 : wrong macro parsing
o 323938 : gtk-doc.m4 check is silent
o 324535 : gtk-doc doesn't handle deprecation inside enumerations
o 355352 : If you don't have an instantiatable type for a gtypeinter...
o 379466 : Improve C parser to handle TYPE\nVARIABLE in function pro...
o 380824 : docs are truncated if line begins with '* returns '
o 383456 : ' make check ' test for 100% documentation
o 411739 : Gtk-doc fails to handle ' struct tm * function_name (); '
o 415388 : Please clean -undocumented.txt files
o 418027 : gtkdoc-mkdb does not handle #ifdef in enum {}
o 419997 : parameter name trouble
o 428596 : Warnings with gtk-doc.m4 macros
o 434134 : fixxrefs like sed for installing pregenerated docs
o 436565 : Report undeclared symbols into a file
o 445596 : Impossible to link a page with an anchor
o 445693 : Does not understand ' unsigned long ' as a type
o 450338 : Make gtk-doc.m4 fail when needed gtk-doc is not installed
o 454916 : gtk-doc should permit generation of URI-based cross-refer...
o 457077 : add --no-implicit-returns to gtkdoc-mkdb
o 459225 : Accept automake-1.10 in autogen.sh
o 459725 : ' jhbuild build gtk-doc ' fails on make
o 460127 : parsing nested union/structs confuses public/private state
o 465365 : [PATCH] gtk-doc does not compile
o 466559 : [CSS] styling <hr />;
o 471014 : G_CONST_RETURN * G_CONST_RETURN * function not picked up
o 477532 : function variables
o 479913 : gtk-doc.notmpl.make is not distributed
o 479923 : distclean test output properly

Contributors

Benjamin Otte
Damon Chaplin
David Nečas
Frederic Peters
Loic Minier
Petteri Räty
Rouslan Solomakhin
Stefan Kost
Sven Herzberg
Yeti

Download
========

http://download.gnome.org/sources/gtk-doc/1.9/

Stefan

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

Re: status gtk-doc towards 1.9

2007-09-30T10:52:30Z

hi,

I found
http://live.gnome.org/MaintainersCorner/Releasing

but I cannout loginto master.gnome.org - any idea?

Stefan

Damon Chaplin wrote:

> On Sun, 2007-07-22 at 22:05 +0300, Stefan Kost wrote:
>> Damon Chaplin wrote:
>>> I'm afraid I don't really want to spend much time on gtk-doc these days.
>>> So you guys will have to take over maintainership, at least for a while.
>>>
>> Fine with me. Of course it would be good if you could look over the changes
>> still. Can you still do the releases? I could prepare the changelog etc.
>
> I don't really want to do anything on gtk-doc for a while, I'm afraid.
>
> Releases are fairly easy to do, just make dist, scp to master.gnome.org
> and use the install-module script on there.
>
> The web pages are in svn, in gtk-web/gtk-doc.
>
>
>>> Though please test changes before committing them, at least with the GTK
>>> docs. (i.e. copy the xml directory, and see if any changes to gtk-doc
>>> affect the xml files badly).
>>>
>> Right now I build the docs for gstreamer and my own projects. I'll add gtk+ to
>> that too. Problem with gtk+ is that without the index-generation patch applied
>> it takes ages :/
>
> You don't need to build the html to test every change. Just the xml
> should be fine.
>
> Damon
>
>

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

Re: releasing 1.9 soon...

2007-09-26T14:41:27Z

On Wed, Sep 26, 2007 at 11:15:32PM +0300, Stefan Kost wrote:

> I am giving up for tonight. jhbuild gives me a bunch of those:
>
> echo '-- Installing ./html/index.sgml' ; \
> /home/ensonic/bin/install-check -m 644 ./html/index.sgml
> /opt/gnome-svn/share/gtk-doc/html/gconf || :; \
> fi
> -- Nothing to install
> gtkdoc-rebase --relative --destdir=
> --html-dir=/opt/gnome-svn/share/gtk-doc/html/gconf
> Unknown option: destdir
> Use of uninitialized value in substitution (s///) at
> /opt/gnome-svn/bin/gtkdoc-rebase line 211.
> Use of uninitialized value in substitution (s///) at
> /opt/gnome-svn/bin/gtkdoc-rebase line 211.
> Can't open HTML directory /opt/gnome-svn/share/gtk-doc/html/gconf/: File or
> Directory not found at /opt/gnome-svn/bin/gtkdoc-rebase line 227.
> make[3]: [install-data-local] Fehler 2 (ignored)
>
> basic problem is that the perl option parse does not like
> "--destdir= --next-option"
> which is caused by empty DESTDIR. Before I add more crack to the rules, I go for
> a sleep. Suggestions are welcome :)

1) --destdir='$(DESTDIR)' or --destdir="$(DESTDIR)".
But then we have the SCAN_OPTIONS situation again if someone
quotes DESTDIR. Incidentally, I see

if test "x$(DESTDIR)" = "x"; then \

in the makefile, which suffers from the same problem.

And if it was there when you were performing the builds,
then I have no idea what's going on.

2) Use

Getopt::Long qw(:config gnu_getopt);

to make Getopt::Long fully GNU getopt_long() compatible. Or
at least :config gnu_compat to change the behaviour of empty
--opt=.

Note however, according to my Getopt::Long man page empty
--opt is either GNU compatible or gives an error. So in no
case it should eat the next option; something strange is
going on here.

3) Change $DESTDIR style from option to an argument and run
it just

gtkdoc-rebase OPTIONS... $DESTDIR

Although rebase has no non-option arguments so this would
work, it's quite ugly and I don't like it.

4) Change the ($DESTDIR, $DESTDIR$TARGET_DIR) pair of
directories to ($TARGET_DIR, $DESTDIR$TARGET_DIR), that are
always defined, and let rebase extract $DESTDIR.

Not very nice either. Passing two competely unrelated
directories as --html-dir and --dest-dir is a bit weird,
nevertheless it makes some sense with --relative (I have
a staging area, but in a different place I'm installing this
particular documentation). In the new pair one directory
would have to be the tail of another.

-------------------------------------------------------------

The only approach that could get my is 2), the rest is just
a dump of random ideas.

I don't know what is the cause of the Getopt::Long behaviour
in jhbuild though.

Yeti

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

Re: releasing 1.9 soon...

2007-09-26T14:15:32Z

Hi,

I am giving up for tonight. jhbuild gives me a bunch of those:

echo '-- Installing ./html/index.sgml' ; \
/home/ensonic/bin/install-check -m 644 ./html/index.sgml
/opt/gnome-svn/share/gtk-doc/html/gconf || :; \
fi
-- Nothing to install
gtkdoc-rebase --relative --destdir=
--html-dir=/opt/gnome-svn/share/gtk-doc/html/gconf
Unknown option: destdir
Use of uninitialized value in substitution (s///) at
/opt/gnome-svn/bin/gtkdoc-rebase line 211.
Use of uninitialized value in substitution (s///) at
/opt/gnome-svn/bin/gtkdoc-rebase line 211.
Can't open HTML directory /opt/gnome-svn/share/gtk-doc/html/gconf/: File or
Directory not found at /opt/gnome-svn/bin/gtkdoc-rebase line 227.
make[3]: [install-data-local] Fehler 2 (ignored)

basic problem is that the perl option parse does not like
"--destdir= --next-option"
which is caused by empty DESTDIR. Before I add more crack to the rules, I go for
a sleep. Suggestions are welcome :)

For some reasons I only get this in jhbuild, but not when building own packages.

Stefan

Stefan Kost wrote:

> Hi again,
>
> I think it looks mostly okay now. Still have some trouble with getting make
> distcheck to work though.
>
> I also run a full jhbuild and have lots of gtk-doc books generated. So at least
> it does not terminate builds. I'll rerun the build, redirect logs and try
> greping for perl warnings.
>
> If nothing else pops up, I'd say ready for release.
>
> Stefan

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

Re: releasing 1.9 soon...

2007-09-25T14:39:28Z

Hi again,

I think it looks mostly okay now. Still have some trouble with getting make
distcheck to work though.

I also run a full jhbuild and have lots of gtk-doc books generated. So at least
it does not terminate builds. I'll rerun the build, redirect logs and try
greping for perl warnings.

If nothing else pops up, I'd say ready for release.

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

Re: releasing 1.9 soon...

2007-09-23T08:20:44Z

Hi,

David Nečas (Yeti) wrote:

> On Sun, Sep 23, 2007 at 02:41:00PM +0300, Stefan Kost wrote:
>> Well then our understanding differs here. If a bug is closed as a reporter I
>> would like to know which release will have the fix. In the case of libraries I
>> could e.g. add a configure check for that version and disable a workaround if
>> the user has a recent enough version.
>
> This is not about understanding, this is about misuse.
> However worthy your goal might be, misuse of bugzilla fields
> should not be the solution.
>
>>> The list is incomplete anyway. What about 322035, 383456,
>>> 445596, 450338, 465365, 466559?
>>>
>>> If you want to know bugs fixed since the last gtk-doc
>>> release, just ask bugzilla for it.
>>>
>> Exactly, therefore I use the field.
>
> And my list is an illustration it does not work[*]. These
> bugs were fixed by 1.9 byt they are not marked with 1.9
> target milestone -- yet I easily found them by asking
> bugzilla.
>

I basicylly grepped the "Fixes #\d+" comments from the changelog. Maybe a query
by date in bugzilla would have work too. Is that what you have done?
Anyway I will now mark the missing one too to have a full list for the release
notes. In the future we shall use this as you said - to schedule bugs.

<snip>

>>> Considering interesting error messages vary wildly (from perl
>>> complaints such as `Use of uninitialized value...' to various
>>> WARNINGs to xsltproc messages), how we find them in the
>>> flood?
>>>
>> I am open to ideas here. Its more a sanity check that ensure that now build
>> aborts etc.
>
> If I knew how to find the start and end of documentation
> build in the logs reliably, I'd just filter out everything
> known to be harmless (Writing foo for refentry(bar)..., ID
> recommended on..., gtk-doc: Running baz..., make:
> Leaving/Entering directory ..., \-continued blocks that
> looks like our commands, ...) and look at what remained.
>
> Perhaps we can assume there is no interesting message before
> `gtk-doc: Scanning header files' and that `touch
> html-build.stamp' is the last thing printed, but it's not
> exactly reliable.
>
> Well, I don't even know how to get the actual logs from
> build.gnome.org. Moreover it seems most interestring builds
> started failing on 16 September due to some infrastructure
> change.

I'll see if I run find some time for yhbuild.

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

Re: releasing 1.9 soon...

2007-09-23T06:35:17Z

On Sun, Sep 23, 2007 at 02:41:00PM +0300, Stefan Kost wrote:
>
> Well then our understanding differs here. If a bug is closed as a reporter I
> would like to know which release will have the fix. In the case of libraries I
> could e.g. add a configure check for that version and disable a workaround if
> the user has a recent enough version.

This is not about understanding, this is about misuse.
However worthy your goal might be, misuse of bugzilla fields
should not be the solution.

> > The list is incomplete anyway. What about 322035, 383456,
> > 445596, 450338, 465365, 466559?
> >
> > If you want to know bugs fixed since the last gtk-doc
> > release, just ask bugzilla for it.
> >
> Exactly, therefore I use the field.

And my list is an illustration it does not work[*]. These
bugs were fixed by 1.9 byt they are not marked with 1.9
target milestone -- yet I easily found them by asking
bugzilla.

Exporting both bug lists to CSV and running diff on them
would reveal the complete set of fixed bugs that cannot be
found by looking for target milestone 1.9.

[*] Of course, you can run the proper query and then use the
mass bug changer to add a milestone to each in the list --
but what's the point when you can use the query?

> How will the user then know that it actaully happend. Once we release 1.10 one
> has to make a query to bugzilla to get all open bug with that target milestone
> and either postpone the release or move that target-milestone to 1.11.

At the moment we release 1.10 there should be no open bugs
with target milestone 1.10.

I'm not sure who `one' is in your description -- target
milestone is a developers' tool to keep track of issues that
should/must be resolved in a particular version or time
frame.

*Before* we (developers) release 1.10 we should deal with
all issues with target milestone 1.10: either resolve them
or decide to postpone them and change the target milestone.

> > Considering interesting error messages vary wildly (from perl
> > complaints such as `Use of uninitialized value...' to various
> > WARNINGs to xsltproc messages), how we find them in the
> > flood?
> >
> I am open to ideas here. Its more a sanity check that ensure that now build
> aborts etc.

If I knew how to find the start and end of documentation
build in the logs reliably, I'd just filter out everything
known to be harmless (Writing foo for refentry(bar)..., ID
recommended on..., gtk-doc: Running baz..., make:
Leaving/Entering directory ..., \-continued blocks that
looks like our commands, ...) and look at what remained.

Perhaps we can assume there is no interesting message before
`gtk-doc: Scanning header files' and that `touch
html-build.stamp' is the last thing printed, but it's not
exactly reliable.

Well, I don't even know how to get the actual logs from
build.gnome.org. Moreover it seems most interestring builds
started failing on 16 September due to some infrastructure
change.

Yeti

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

Re: releasing 1.9 soon...

2007-09-23T05:41:00Z

Hi,

David Nečas (Yeti) wrote:

> On Sat, Sep 22, 2007 at 11:09:45PM +0300, Stefan Kost wrote:
>> I hope now all patches have been applied. I also added a target milestone to the
>> bug we fixed in this cycle.
>
> Please don't. Bugzilla Target Milestone field is intended
> for open bugs -- to track what to get done in a particular
> version, timeframe, ... Generally, it's a classification of
> when in the future the issue is expected to be resolved.
>
> (The stricter Gnome Target Milestone means that Gnome X.Y
> cannot be released until all open bugs with X.Y milestone
> are fixed.)

Well then our understanding differs here. If a bug is closed as a reporter I
would like to know which release will have the fix. In the case of libraries I
could e.g. add a configure check for that version and disable a workaround if
the user has a recent enough version.

>
>> This allow me to pull the buglist out of bugzilla
>> fro the release notes - sorry for the resulting spam.
>
> The list is incomplete anyway. What about 322035, 383456,
> 445596, 450338, 465365, 466559?
>
> If you want to know bugs fixed since the last gtk-doc
> release, just ask bugzilla for it.
>

Exactly, therefore I use the field.

>
>> I have also created 1.10
>> target milestone, so please us that when closing bugs after the release.
>
> While 1.10 target milestone is a good idea, I'm going to
> mark bugs that should be fixed in 1.10 with it (e.g. the
> postponed VPATH stuff) because this is what this flag means.
>
How will the user then know that it actaully happend. Once we release 1.10 one
has to make a query to bugzilla to get all open bug with that target milestone
and either postpone the release or move that target-milestone to 1.11.

>
>> Next I'll try to see if the build.gnome.org could run build with snv-trunk
>> version of gtk-doc. If I have time I'll try a jhbuild of gnome-2.20 locally too.
>
> Considering interesting error messages vary wildly (from perl
> complaints such as `Use of uninitialized value...' to various
> WARNINGs to xsltproc messages), how we find them in the
> flood?
>
I am open to ideas here. Its more a sanity check that ensure that now build
aborts etc.

Stefan

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

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

Re: releasing 1.9 soon...

2007-09-22T16:42:21Z

On Sat, Sep 22, 2007 at 11:09:45PM +0300, Stefan Kost wrote:
>
> I hope now all patches have been applied. I also added a target milestone to the
> bug we fixed in this cycle.

Please don't. Bugzilla Target Milestone field is intended
for open bugs -- to track what to get done in a particular
version, timeframe, ... Generally, it's a classification of
when in the future the issue is expected to be resolved.

(The stricter Gnome Target Milestone means that Gnome X.Y
cannot be released until all open bugs with X.Y milestone
are fixed.)

> This allow me to pull the buglist out of bugzilla
> fro the release notes - sorry for the resulting spam.

The list is incomplete anyway. What about 322035, 383456,
445596, 450338, 465365, 466559?

If you want to know bugs fixed since the last gtk-doc
release, just ask bugzilla for it.

> I have also created 1.10
> target milestone, so please us that when closing bugs after the release.

While 1.10 target milestone is a good idea, I'm going to
mark bugs that should be fixed in 1.10 with it (e.g. the
postponed VPATH stuff) because this is what this flag means.

> Next I'll try to see if the build.gnome.org could run build with snv-trunk
> version of gtk-doc. If I have time I'll try a jhbuild of gnome-2.20 locally too.

Considering interesting error messages vary wildly (from perl
complaints such as `Use of uninitialized value...' to various
WARNINGs to xsltproc messages), how we find them in the
flood?

Yeti

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

Re: releasing 1.9 soon...

2007-09-22T14:09:45Z

hi,

I hope now all patches have been applied. I also added a target milestone to the
bug we fixed in this cycle. This allow me to pull the buglist out of bugzilla
fro the release notes - sorry for the resulting spam. I have also created 1.10
target milestone, so please us that when closing bugs after the release.

Next I'll try to see if the build.gnome.org could run build with snv-trunk
version of gtk-doc. If I have time I'll try a jhbuild of gnome-2.20 locally too.

Stefan

David Nečas (Yeti) wrote:

> Following the gtk-devel discussion, if we want $SUBJ, things
> concerning srcdir != builddir can be postponed IMO (it has
> never worked properly anyway), and only the following should
> be dealt with:
>
> http://bugzilla.gnome.org/show_bug.cgi?id=338068
> enable template-free build
> I'll look at the xml cleaning.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=433338
> Doesn't rebuild the documentation when the .types file changes
> As suggesed, I would close as WONTFIX.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=466963
> 1.8 makes make distcheck fail
> I would close as NOTABUG, but this is politics...
>
> http://bugzilla.gnome.org/show_bug.cgi?id=471014
> G_CONST_RETURN * G_CONST_RETURN * function not picked up
> Simple and a patch is available.
>
> That and the misguided --online option still present in
> fixxref.
>
> Then we should give it a good testing.
>
> Yeti
>
> --
> http://gwyddion.net/
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-doc-list

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

Re: releasing 1.9 soon...

2007-09-19T13:30:26Z

On Wed, Sep 19, 2007 at 08:54:55PM +0300, Stefan Kost wrote:
> regarding gtkdoc-fixxref.pl should I just revert that patch:
> http://bugzilla.gnome.org/attachment.cgi?id=91852

It seems, I don't recall any related change that would have
to be reverted, the feature has never been actually used.

> Regarding your proposal below - sounds good. So this means we merely document
> that users can use DISTCLEANFILES in the userdocs and in the gtkdoc.mak. Can you
> suppy a new patch?

Of course.

> Ich checked out the webpage and will start to prepare release notes.

IMO we should test build of documentation of Gnome 2.20
versions of everything at

http://library.gnome.org/devel/references

before releasing a new gtk-doc. People of course built
their API documentation, but not necessarily with what we
are going to release and not looking for the same kind of
issues we would.

Yeti

--
http://gwyddion.net/

Index: gtk-doc.make
===================================================================
--- gtk-doc.make (revision 493)
+++ gtk-doc.make (working copy)
@@ -165,6 +165,7 @@
cp $(srcdir)/html/* $(distdir)/html
cp $(srcdir)/$(DOC_MODULE).types $(distdir)/
cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/
+ cd $(distdir) && rm -f $(DISTCLEANFILES)
-gtkdoc-rebase --online --relative --html-dir=$(distdir)/html

.PHONY : dist-hook-local docs
Index: gtk-doc.notmpl.make
===================================================================
--- gtk-doc.notmpl.make (revision 493)
+++ gtk-doc.notmpl.make (working copy)
@@ -146,6 +146,7 @@
cp $(srcdir)/html/* $(distdir)/html
cp $(srcdir)/$(DOC_MODULE).types $(distdir)/
cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/
+ cd $(distdir) && rm -f $(DISTCLEANFILES)
-gtkdoc-rebase --online --relative --html-dir=$(distdir)/html

.PHONY : dist-hook-local docs

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

Re: releasing 1.9 soon...

2007-09-19T11:54:55Z

Hi,

regarding gtkdoc-fixxref.pl should I just revert that patch:
http://bugzilla.gnome.org/attachment.cgi?id=91852
I've did a dry-run and it still applies.

Regarding your proposal below - sounds good. So this means we merely document
that users can use DISTCLEANFILES in the userdocs and in the gtkdoc.mak. Can you
suppy a new patch?

Ich checked out the webpage and will start to prepare release notes.

Stefan

David Nečas (Yeti) wrote:

> On Mon, Sep 17, 2007 at 06:58:21PM +0200, David Nečas (Yeti) wrote:
>> This does not work either...
>
> A method that has a good chance to work:
>
> Do not try to parse SCAN_OPTIONS and let the user add the
> files to DISTCLEANFILES (gtk-doc.make does not use it
> internally) manually.
>
> Happily copy everything to $(distdir) in the dist hook and
> then do something like
>
> cd $(distdir) && rm -f $(DISTCLEANFILES)
>
> in the dist hook (putting the files in DISTCLEANFILES
> already takes care of cleaning them in distclean).
>
> Although DISTCLEANFILES can in principle contain all kinds
> of shell code too, it is quite unlikely to contain
> anything fragile because people cannot be sure precisely
> how automake uses it.
>
> An advantage of this approach is its universality: The user
> does not want to distribute some files -- any files -- so he
> adds them to DISTCLEANFILES. And that's all, they are
> correctly dist-cleaned and excluded from distribution.
>
> Yeti
>
> --
> http://gwyddion.net/
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-doc-list

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

Re: releasing 1.9 soon...

2007-09-18T12:04:41Z

On Mon, Sep 17, 2007 at 06:58:21PM +0200, David Nečas (Yeti) wrote:
> This does not work either...

A method that has a good chance to work:

Do not try to parse SCAN_OPTIONS and let the user add the
files to DISTCLEANFILES (gtk-doc.make does not use it
internally) manually.

Happily copy everything to $(distdir) in the dist hook and
then do something like

cd $(distdir) && rm -f $(DISTCLEANFILES)

in the dist hook (putting the files in DISTCLEANFILES
already takes care of cleaning them in distclean).

Although DISTCLEANFILES can in principle contain all kinds
of shell code too, it is quite unlikely to contain
anything fragile because people cannot be sure precisely
how automake uses it.

An advantage of this approach is its universality: The user
does not want to distribute some files -- any files -- so he
adds them to DISTCLEANFILES. And that's all, they are
correctly dist-cleaned and excluded from distribution.

Yeti

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

Re: releasing 1.9 soon...

2007-09-17T10:58:21Z

On Mon, Sep 17, 2007 at 04:47:39PM +0200, Stefan Kost wrote:
> allthough ugly, adding a gtkdoc-disthelper script that gets invoked on
> dist-hook:
> gtkdoc-disthelper $(SCAN_OPTIONS)
> distclean-local:
> gtkdoc-disthelper $(SCAN_OPTIONS)
> could help.

This does not work either, see for instance gtk-doc's own
test suite which sets the variable

SCAN_OPTIONS=--deprecated-guards="GTKDOC_TESTER_DISABLE_DEPRECATED" 2>&1 | tee gtkdoc-scan.log

I.e., make distclean would create file gtk-scan.log.

Yeti

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

Re: releasing 1.9 soon...

2007-09-17T10:56:07Z

On Mon, Sep 17, 2007 at 05:00:28PM +0200, Stefan Kost wrote:
> actually, I think its only the quoting that needs a change:
> -case "x $(SCAN_OPTIONS) " in \
> +case 'x $(SCAN_OPTIONS) ' in \
>
> then it works for me

No, it does not. It only means you do not have anything
quoted with single quotes in $(SCAN_OPTIONS).

The basic trouble is that make does not care about the
underlying syntax, it just substitutes text, therefore no
quoting can work.

Yeti

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

Re: releasing 1.9 soon...

2007-09-17T09:00:28Z

hi,

actually, I think its only the quoting that needs a change:
-case "x $(SCAN_OPTIONS) " in \
+case 'x $(SCAN_OPTIONS) ' in \

then it works for me

Stefan

Quoting Matthias Clasen <matthias.clasen@...>:

> On 9/8/07, David Nečas (Yeti) <yeti@...> wrote:
>>
>> Following the gtk-devel discussion, if we want $SUBJ, things
>> concerning srcdir != builddir can be postponed IMO (it has
>> never worked properly anyway), and only the following should
>> be dealt with:
>>
>
> Here is one problem I found today while trying to do a gtk 2.12.0
> release with
> svn gtk-doc:
>
> [...]
>
> mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/tmpl
> mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/xml
> mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/html
> cp ./tmpl/*.sgml ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/tmpl
> cp ./xml/*.xml ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/xml
> cp ./html/* ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/html
> case "x --source-dir=../../../contrib/gdk-pixbuf-xlib
> --deprecated-guards="GDK_PIXBUF_ENABLE_BROKEN|GDK_PIXBUF_DISABLE_DEPRECATED"
> " in \
> *' --rebuild-types '*) ;; \
> *) cp ./gdk-pixbuf.types
> ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/;; \
> esac
> /bin/sh: -c: line 0: syntax error near unexpected token `|'
> /bin/sh: -c: line 0: `case "x
> --source-dir=../../../contrib/gdk-pixbuf-xlib
> --deprecated-guards="GDK_PIXBUF_ENABLE_BROKEN|GDK_PIXBUF_DISABLE_DEPRECATED"
> " in \'
> make[4]: *** [dist-hook] Error 2
>
>
> This comes from the following part of gtk-doc.make:
>
> distclean-local:
> cd $(srcdir) && \
> rm -rf xml $(REPORT_FILES) \
> $(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt
> case "x $(SCAN_OPTIONS) " in \
> *' --rebuild-types '*) rm -f $(srcdir)/$(DOC_MODULE).types;; \
> esac
> case "x $(SCAN_OPTIONS) " in \
> *' --rebuild-sections '*) rm -f
> $(srcdir)/$(DOC_MODULE)-sections.txt;; \
> esac
>
>
> Any chance to make that work with existing uses of gtk-doc before
> releasing 1.9 ?
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-doc-list
>

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

Re: releasing 1.9 soon...

2007-09-17T08:47:39Z

hi,

allthough ugly, adding a gtkdoc-disthelper script that gets invoked on
dist-hook:
gtkdoc-disthelper $(SCAN_OPTIONS)
distclean-local:
gtkdoc-disthelper $(SCAN_OPTIONS)
could help.

Stefan

Quoting "David Nečas (Yeti)" <yeti@...>:

> On Fri, Sep 14, 2007 at 01:55:42AM +0200, David Nečas (Yeti) wrote:
>> Well, it's always possible to distribute the files even if
>> they are generated and useless.
>
> Stefan, please apply the attached patch. I can't see any
> reliable method to check whether types and sections are
> built files that would be less ugly than distributing them
> even if they are built.
>
> Yeti
>
> --
> http://gwyddion.net/
>

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

Re: releasing 1.9 soon...

2007-09-14T02:27:53Z

On Fri, Sep 14, 2007 at 01:55:42AM +0200, David Nečas (Yeti) wrote:
> Well, it's always possible to distribute the files even if
> they are generated and useless.

Stefan, please apply the attached patch. I can't see any
reliable method to check whether types and sections are
built files that would be less ugly than distributing them
even if they are built.

Yeti

--
http://gwyddion.net/

Index: gtk-doc.make
===================================================================
--- gtk-doc.make (revision 490)
+++ gtk-doc.make (working copy)
@@ -123,12 +123,6 @@
cd $(srcdir) && \
rm -rf xml $(REPORT_FILES) \
$(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt
- case "x $(SCAN_OPTIONS) " in \
- *' --rebuild-types '*) rm -f $(srcdir)/$(DOC_MODULE).types;; \
- esac
- case "x $(SCAN_OPTIONS) " in \
- *' --rebuild-sections '*) rm -f $(srcdir)/$(DOC_MODULE)-sections.txt;; \
- esac

maintainer-clean-local: clean
cd $(srcdir) && rm -rf xml html
@@ -169,14 +163,8 @@
-cp $(srcdir)/tmpl/*.sgml $(distdir)/tmpl
-cp $(srcdir)/xml/*.xml $(distdir)/xml
cp $(srcdir)/html/* $(distdir)/html
- case "x $(SCAN_OPTIONS) " in \
- *' --rebuild-types '*) ;; \
- *) cp $(srcdir)/$(DOC_MODULE).types $(distdir)/;; \
- esac
- case "x $(SCAN_OPTIONS) " in \
- *' --rebuild-sections '*) ;; \
- *) cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/;; \
- esac
+ cp $(srcdir)/$(DOC_MODULE).types $(distdir)/
+ cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/
-gtkdoc-rebase --online --relative --html-dir=$(distdir)/html

.PHONY : dist-hook-local docs
Index: gtk-doc.notmpl.make
===================================================================
--- gtk-doc.notmpl.make (revision 490)
+++ gtk-doc.notmpl.make (working copy)
@@ -108,12 +108,6 @@
cd $(srcdir) && \
rm -rf xml $(REPORT_FILES) \
$(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt
- case "x $(SCAN_OPTIONS) " in \
- *' --rebuild-types '*) rm -f $(srcdir)/$(DOC_MODULE).types;; \
- esac
- case "x $(SCAN_OPTIONS) " in \
- *' --rebuild-sections '*) rm -f $(srcdir)/$(DOC_MODULE)-sections.txt;; \
- esac

maintainer-clean-local: clean
cd $(srcdir) && rm -rf html
@@ -150,14 +144,8 @@
dist-hook: dist-check-gtkdoc dist-hook-local
mkdir $(distdir)/html
cp $(srcdir)/html/* $(distdir)/html
- case "x $(SCAN_OPTIONS) " in \
- *' --rebuild-types '*) ;; \
- *) cp $(srcdir)/$(DOC_MODULE).types $(distdir)/;; \
- esac
- case "x $(SCAN_OPTIONS) " in \
- *' --rebuild-sections '*) ;; \
- *) cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/;; \
- esac
+ cp $(srcdir)/$(DOC_MODULE).types $(distdir)/
+ cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/
-gtkdoc-rebase --online --relative --html-dir=$(distdir)/html

.PHONY : dist-hook-local docs

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

Re: releasing 1.9 soon...

2007-09-13T17:55:42Z

On Thu, Sep 13, 2007 at 07:35:11PM -0400, Matthias Clasen wrote:

>
> Here is one problem I found today while trying to do a gtk 2.12.0 release with
> svn gtk-doc:
> ...
>
> This comes from the following part of gtk-doc.make:
>
> distclean-local:
> cd $(srcdir) && \
> rm -rf xml $(REPORT_FILES) \
> $(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt
> case "x $(SCAN_OPTIONS) " in \
> *' --rebuild-types '*) rm -f $(srcdir)/$(DOC_MODULE).types;; \
> esac
> case "x $(SCAN_OPTIONS) " in \
> *' --rebuild-sections '*) rm -f
> $(srcdir)/$(DOC_MODULE)-sections.txt;; \
> esac

Ah, and I thought how clever I was and instead I made the
textbook make expansion mistake...

> Any chance to make that work with existing uses of gtk-doc before
> releasing 1.9 ?

Of course, except that all methods I can imagine to check
the content of a make variable in a rule scriptlet are
non-portable or break in some cases.

The only method that would in the worst case just fail to
see the option seems to be extracting the value of the
variable from Makefile with sed. And that's rather silly.

Well, it's always possible to distribute the files even if
they are generated and useless.

Yeti

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

Re: releasing 1.9 soon...

2007-09-13T17:35:11Z

On 9/8/07, David Nečas (Yeti) <yeti@...> wrote:
>
> Following the gtk-devel discussion, if we want $SUBJ, things
> concerning srcdir != builddir can be postponed IMO (it has
> never worked properly anyway), and only the following should
> be dealt with:
>

Here is one problem I found today while trying to do a gtk 2.12.0 release with
svn gtk-doc:

[...]

mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/tmpl
mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/xml
mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/html
cp ./tmpl/*.sgml ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/tmpl
cp ./xml/*.xml ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/xml
cp ./html/* ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/html
case "x --source-dir=../../../contrib/gdk-pixbuf-xlib
--deprecated-guards="GDK_PIXBUF_ENABLE_BROKEN|GDK_PIXBUF_DISABLE_DEPRECATED"
" in \
*' --rebuild-types '*) ;; \
*) cp ./gdk-pixbuf.types
../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/;; \
esac
/bin/sh: -c: line 0: syntax error near unexpected token `|'
/bin/sh: -c: line 0: `case "x
--source-dir=../../../contrib/gdk-pixbuf-xlib
--deprecated-guards="GDK_PIXBUF_ENABLE_BROKEN|GDK_PIXBUF_DISABLE_DEPRECATED"
" in \'
make[4]: *** [dist-hook] Error 2

This comes from the following part of gtk-doc.make:

distclean-local:
cd $(srcdir) && \
rm -rf xml $(REPORT_FILES) \
$(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt
case "x $(SCAN_OPTIONS) " in \
*' --rebuild-types '*) rm -f $(srcdir)/$(DOC_MODULE).types;; \
esac
case "x $(SCAN_OPTIONS) " in \
*' --rebuild-sections '*) rm -f
$(srcdir)/$(DOC_MODULE)-sections.txt;; \
esac

Any chance to make that work with existing uses of gtk-doc before
releasing 1.9 ?
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

Re: releasing 1.9 soon...

2007-09-10T14:02:44Z

On Mon, Sep 10, 2007 at 10:14:24PM +0300, Stefan Kost wrote:
> http://bugzilla.gnome.org/show_bug.cgi?id=448879
> Use a footer when generating HTML documentation
> -> I don't adding a footer so much

I don't have any opinion. I view documentation with dillo,
therefore it has been always working for me...

Design-wise, large spacer at the bottom is an issue mainly
if it's followed by a footer.

> http://bugzilla.gnome.org/show_bug.cgi?id=338342
> pkg-config check in gtk-doc.m4 isn't versionned
> -> closing?

Dunno, shouldn't we check for pkg-config >= 0.19 in
gtk-doc.m4 as suggested? What

# Make sure we have pkg-config >= 0.19, so installing in $(datadir) is OK.

in gtk-doc's configure.in tries to achieve?

Yeti

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