After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 657922 - glob support for IGNORE_HFILES
glob support for IGNORE_HFILES
Status: RESOLVED OBSOLETE
Product: gtk-doc
Classification: Platform
Component: general
1.18
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-doc maintainers
gtk-doc maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-01 12:28 UTC by Michał Górny
Modified: 2018-05-22 13:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
allow wildcards in IGNORE_HFILES (1.51 KB, patch)
2013-06-04 19:14 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
none Details | Review

Description Michał Górny 2011-09-01 12:28:06 UTC
After declaring a private struct in one of my private header files:

	struct _notification {
		...
	};

gtk-doc lists it as unused. Moreover, it lists it with '_' stripped:

	notification

Is that actually expected?
Comment 1 Yeti 2011-09-01 12:36:57 UTC
Just a comment: if the entire header is private put

/*<private_header>*/

there to tell gtk-doc to skip it.

This is a consequence of struct _foo { }; being normally accompanied with typedef struct _foo foo; (for public structs).  I don't know what would or would not break if gtk-doc stopped doing this.
Comment 2 Michał Górny 2011-09-01 12:41:07 UTC
Well, in my case struct _foo is mapped to Foo type. Maybe I should rename it to _Foo instead.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2011-09-05 07:42:06 UTC
Michal, do you let gtk-doc scan that private header? Try adding the header to IGNORE_HFILE in Makefile.am. That can be a glob too, e.g. IGNORE_HFILE=*-private.h
Comment 4 Michał Górny 2011-09-05 07:50:41 UTC
Hm, IGNORE_HFILES seems even a better solution but I'm unable to get it working.

I've got:

	HFILE_GLOB = $(top_srcdir)/lib/*.h

I tried setting IGNORE_HFILES to *_.h, lib/*_.h and even $(top_srcdir)/lib/*_.h; neither works.
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2011-09-05 07:55:03 UTC
Sorry IGNORE_HFILES is not a glob. I'll see if I can make it one for 0.18. Right now it just matches the file part in all working directories. SO its better to do
IGNORE_HFILES = file1_.h file2_.h
Comment 6 Yeti 2011-09-05 07:56:51 UTC
I have better experience with encoding the information that the header is private into the header itself because it can be then used by other scripts and tools.
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2011-09-05 08:01:25 UTC
Yeti, do you thing doing glob expansion would be useful in IGNORE_HFILES? It would be convenient and more portable than using $(shell ) in the makefile.
Comment 8 Yeti 2011-09-05 08:11:51 UTC
IMO it would since you want to distinguish between private and public headers just from looking at them.  So if you have any system in it either the content or the name of the file encode it.  While /*<private_header>*/ works for content, globs would work for names.
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2011-09-14 14:17:37 UTC
Michał, are you fine now?
Comment 10 Michał Górny 2011-09-14 15:16:57 UTC
(In reply to comment #9)
> Michał, are you fine now?

To be honest, I was looking for progress on the globs. Not that I really need this but it seems better that either all variables have explicit file lists or all of them use globs.
Comment 11 Stefan Sauer (gstreamer, gtkdoc dev) 2013-06-04 19:14:08 UTC
Created attachment 246027 [details] [review]
allow wildcards in IGNORE_HFILES

This would require to use a module like Text::Glob. Any other idea?
Comment 12 Stefan Sauer (gstreamer, gtkdoc dev) 2013-06-05 05:09:26 UTC
The whole IGNORE_HFILES feature is somewhat bad, as we'd still have doc rebuilds when ignored headers are changed. Ideally one could exclude the files already on the HFILE_GLOB.
Comment 13 GNOME Infrastructure Team 2018-05-22 13:05:42 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk-doc/issues/18.