Bug 263781 - devel/devhelp: Adding options for docs and editor plugin to port build
Summary: devel/devhelp: Adding options for docs and editor plugin to port build
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-05 04:04 UTC by Sean Champ
Modified: 2022-05-10 07:09 UTC (History)
2 users (show)

See Also:
fernape: maintainer-feedback? (gnome)


Attachments
patch for devhelop port options (docs, editor plugins) (12.64 KB, patch)
2022-05-05 04:04 UTC, Sean Champ
no flags Details | Diff
patch for devhelp port options (11.91 KB, patch)
2022-05-05 06:15 UTC, Sean Champ
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sean Champ 2022-05-05 04:04:06 UTC
Created attachment 233731 [details]
patch for devhelop port options (docs, editor plugins)

When searching for the devhelp documentation for devhelp, I'd noticed that there are some meson options that are available for the devehlp build.

This patch - attached - adds options for docs and editor plugins to the port build

In all candor, I haven't tested the editor plugings or reviewed the docs for their availability and presentation in devhelp. I've tested the patch on the Makefile and PLIST, and it seems to build.

Aside to the port build, related to devhelop though perhaps I should add a second bug item for this I'm not certain if all ports are installing their *.devhelp2 files into a place that could be accessed by devhelp. For instance, the cairo devehlp2 file has been installed to
/usr/local/share/doc/cairo/cairo/cairo.devhelp2
but I don't see the Cairo API docs showing up in the devhelp browser. On a search for 'cairo' the only docs I'm finding are for cairomm.

There might seem to be a few ports with .devhelp2 files not installed under .... it seems that the path might be /usr/local/share/devhelp/books/<pkgdir>/

I assume that the <pkgdir> might be derived from the pkgconf/pkgconfig pkg name.

AFter this patch in this present revision, devel/devhelp itself would be added to that list of ports installing *.devhelp2 files under DOCSDIR.

Candidly, I'm not immediately aware of how the paths thing works out in devhelp. Maybe there's a devhelp analogy to MANPATH? I hope it's mentioned in the documentation, lol (hence the patch version 1)

If to provide support for ports with a gtkdoc option that build and install a devhelp2 file under some config, then to ensure if  ports' devhelp2 files would be installed under e.g /usr/local/share/devhelp/books/<pkgdir>/ (if that's the dir for it) could there be a possibility in FreeBSD ports for adding a 'devehelp' feature under USES=gnome or some other USES property?

Of course, it may be possible for a devhelp2 file to be installed without GNOME. After some local hacks, maybe the devhelp browser could even be used for browsing Ruby docs from rdoc/YARD, with some appropriate templates and formatting on the Ruby side.
Comment 1 Sean Champ 2022-05-05 04:08:37 UTC
renamed bug, devel/devhelp is the port name without typos
Comment 2 Sean Champ 2022-05-05 04:26:54 UTC
With the patched port built with the DOCS option, I'm seeing a devhelp entry under the index in the Devhelp GUI/browser. This is with the devhelp2 file installed under DOCSDIR

The documentation there does not seem to explain how Devhelp finds files. I'm not sure why the cairo docs entry isn't showing up, will look for more documentation about devhelp
Comment 3 Sean Champ 2022-05-05 04:39:29 UTC
The devhelp documentation also shows up under yelp, as "Devhelp User Documentation"
Comment 4 Sean Champ 2022-05-05 05:04:36 UTC
I've added maintainer to CC. That had been missed due to a typo in topic line for the the initial patch.

It seems that the patched port will have installed two separate manuals under DOCSDIR - i.e the devhelp API docs (visible in Devhelp, and browsable from the shell with Yelp). Looking at the pkg-plist again, it seems that this manual was already being built and installed - Yelp is probably using the *.page files listed in the pkg-plist. Those were already being installed, then available from the Yelp top index.

Looking at the devhelp documentation, should *.devhelp2 files and their linked HTML and image files all be installed under /usr/local/share/gtk-doc/html/<PORTNAME>/ ? That's where the gtk3 and gdk3 devhelp docs are installed, for instance. 

Albeit, somehow the Devehelop browser is finding Devhelp's own devhelp docs without those being installed to such a directory.

Assuming that the patched port should probably install the API docs for devehlp under that dir, for consistency, I'll update and add a new diff
Comment 5 Sean Champ 2022-05-05 05:53:17 UTC
If installing the devhelp HTML files and *.devhelp2 under ${PREFIX}/share/gtk-doc/html/${PORTNAME} then the Devhelp documentation browser actually cannot find that documentation file.

Maybe it wouldn't seem very tidy for the number of files that the docs option installs under the effective DOCSDIR, with the patch as-is. I'm not certain of how to ensure Devhelp would actually find those documentation files if installed under ${PREFIX}/share/gtk-doc/html/${PORTNAME}
Comment 6 Sean Champ 2022-05-05 06:15:11 UTC
Created attachment 233734 [details]
patch for devhelp port options

This updated patch would provide essentially the same behavior as the previous version of this patch. In the updated patch, DOCSDIR will be set as to match where files would be installed with the docs option enalbed.

With this docs option enabled, there would be two manuals installed - the Devhelp User Docs under Yelp, and the Devhelp API docs then available under the Devhelp browser on the desktop.

The Devhelp User Docs are already being installed with the port. This patch just adds an option for the API docs and the editor plugins, also updating pkg-plist.
Comment 7 Fernando Apesteguía freebsd_committer freebsd_triage 2022-05-10 07:09:51 UTC
^Triage: [tags] in issue Titles are deprecated.

^Triage: Simplifying title


Thanks!