Opened 14 years ago
Closed 14 years ago
#2633 closed defect (fixed)
Doc directory for udev
| Reported by: | Jeremy Huntwork | Owned by: | Matthew Burgess |
|---|---|---|---|
| Priority: | normal | Milestone: | 6.7 |
| Component: | Book | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description
At least with udev-151, the --docdir switch doesn't appear to do what LFS expects. Using the configure switches in the current book we end up with html files for libudev in /usr/share/gtk-doc/html/libudev, which appears to be the default location. If you prefer to have those files in the directory indicated by the current --docdir switch, you should use the --with-html-dir switch instead.
Change History (6)
follow-up: 3 comment:1 by , 14 years ago
comment:2 by , 14 years ago
Confirmed. The only doc I have in that directory is README.keymap.txt which got there by a Udev rebuild in BLFS to get all the extras.
follow-up: 4 comment:3 by , 14 years ago
Replying to bryan@…:
Given what those docs are (at least as of udev-146... I need to upgrade...), I think they should either stay where they are, or be deleted.
Thanks, I appreciate your thoughts on this. Packaging in rpm definitely has some advantages, since it forces you to account for all the files installed and decide if they belong in the main package or a sub-package. Since they're HTML format, why specifically do they belong in a gtk-doc directory? Sorry for my ignorance on this, never worked with gtk-doc before. Are there things specific to gtk-doc about those files?
comment:4 by , 14 years ago
Replying to jhuntwork:
Since they're HTML format, why specifically do they belong in a gtk-doc directory?
Just because that's where all the rest of the HTML docs that gtk-doc builds (from comments in the code, IIRC) get installed -- most gtk-ish or gnome-ish packages tend to drop something there. I have directories for all the gtk packages, plus gladeui, lots of bits of gimp, libsoup, libxml2, pygtk, and rsvg, in there on my system.
No really good reason other than "that's what all the packages similar to this do", though.
Sorry for my ignorance on this, never worked with gtk-doc before. Are there things specific to gtk-doc about those files?
Just the tool that was used to create them, and (because of that) the general layout and style.
(I've actually never run gtk-doc myself either. These files get built on the development machine, then get included in the released tarball. You can use --with-gtk-doc (or whatever the configure switch is) to rebuild them if you want, but otherwise there's a Makefile piece that dumps them into /usr/share/gtk-doc/html/${package}.)
Now, that being said, I don't know why the gtk-doc people wrote that snippet to use /usr/share/gtk-doc instead of /usr/share/doc. Perhaps because gtk+ already had a /usr/share/doc/gtk+ directory, with entirely different contents? (Not at all an API reference, more of a developer tutorial plus a FAQ. Not information that fits into code comments.)
comment:5 by , 14 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
I think that all LFS needs to do here is remove the --docdir flag. The location of the libudev html files is consistent with other docs produced using gtk-doc so seems OK to me.
Hmm.
Given what those docs are (at least as of udev-146... I need to upgrade...), I think they should either stay where they are, or be deleted.
They're libudev API HTML-format docs, similar in format to what's stored in /usr/share/gtk-doc/html/gtk/index.html by GTK+. (Those same docs are available at http://library.gnome.org/devel/gtk/stable/ if you don't have GTK+ installed.) /usr/share/gtk-doc is really the right tree for that stuff.
It looks like there isn't really anything in any path matching /usr/share/doc/udev* anymore, except for files we put there as of -146. Looking through Makefile.am in a synced-to-upstream udev git tree also shows only one extra (keymap) dropping anything into docdir (dist_doc_DATA = extras/keymap/README.keymap.txt), but that's inside an "if ENABLE_EXTRAS" check, so we don't build it anyway.
We probably need to update the installation instructions; if udev isn't dumping anything into --docdir, there's really no point in giving it that argument. But someone (me, if I get more than 20 minutes or so here anytime soon) should probably verify that it really doesn't dump anything there the way we configure it today.