On 2020/01/06 05:36, Heppler, J. Scott wrote: > ./configure --help > Produce a config.mk file to be sourced by Makefile > --with-xfce4-panel-applet Include xfce4-panel-applet. This has quite > different > runtime dependencies, so consider building > separately. > --with-gtktheme Include gtktheme module > --with-lx Include lx module > --with-pmenu Include pmenu module > --all, -a Include all contrib/ packages above > --enable-asan Enable address sanitizer (only during development) > --prefix=<dir> Install architecture-independent files in $prefix > (e.g. --prefix=$HOME') > > Dependencies > ------------ > > ## src/ programs > > - jgmenu > > * libx11, libxrandr, cairo, pango, librsvg, glib-2.0 > > - apps > > * Nothing - not even a menu package :) > > - ob > > * libxml2 > > ## contrib/ programs > > - lx > > * glib-2.0, libmenu-cache (>=1.1.0) > * A `menu package` such as lxmenu-data or gnome-menus. Xfce's > libgarcon-common does not yet work with lx. > > - pmenu > > * python3 > * A `menu package` is optional. If none is installed, all applications will > be shown in the menu's root directory. > > - xfce-panel > > * xfce4-panel > > Upstreams position: > > "contrib/ software > > The tools and helpers in this directory: > > are stand-alone, hopefully interesting and sometimes experimental; > > are included in the git-repo to give users easier access to them; > > have sometimes been entirely contributed by others; > > are not installed by default, but can optionally be added to make && > make install (those that are considered mature enough, can be given as > options to the configure script - e.g. --with-lx) > > may have completely different dependencies to the core jgmenu > application (e.g. ff-bookmarks depends on sqlite3 and arguably also > firefox/iceweasel); > > do not always adhere to the jgmenu coding guidelines. > > Although I will try to maintain this code, my main focus will remain on > the jgmenu app itself (the code in the src/ directory)." > > Reference Porters Handbook: > "In the ideal case, build options will simply create new files, with new > dependencies, and not affect other stuff. This is a fairly common > scenario for plugin frameworks: you add one library, you end up with a > new plugin. This also happens fairly often for core applications with a > graphics front-end: the console application is built every time, and the > x11 interface shows up as a separate binary." > > My read of this is that the Core program is jgmenu/apps/ob > and the potential subpackages lx, pmenu and xfce4-panel. > > I'll dismiss xfce4-panel due to the runtime dependencies. > PKGNAME-main=jgmenu > PKGNAME-lx=jgmenu-lx > PKGNAME-pmenu=jgmenu-pmenu > > I'm testing the apps module now and will hopefully have a modified port > by the end of the week.
So looking at the dependencies you listed above, there's no point splitting off pmenu, because jgmenu itself depends on glib2, and glib2 depends on python 3. Same for ob, because jgmenu depends on librsvg which depends on libxml2. lx maybe worth being split off with the relevant run dep's, same for the new xfce menu (having the dependencies split it exactly why multi packages would be used), though I see we currently just have all the menus in the main package and tell users to add the optional dependencies in README, that's valid too IMO and does keep the port simpler ...
