> I drafted that mentioned USE_EXPAND idea as a means to get some > 'design from the scratch' discussion going and flesh out this way of > potentially doing it (such a USE_EXPAND was idly mentioned at start > by > others as something that was deemed too crazy, but I didn't find any > references). It is currently still as a draft over at > http://piratepad.net/iwvgjB1P5d
For the javascript restricted and for purposes of in-line quoted replies, here's the current state of my braindump there copied to e- mail here: The following draft concerns only applications. Libraries should continue using qt4 and qt5 USE flags when they are about libraries (linking against qt4 or qt5), where it's mostly a matter of USE depends by consumer apps or higher level libraries, not user choice for applications. For gtk case, we would use IUSE="gtk2" and IUSE="gtk3" in this case, but ideally they would be in separate slots or packages. In gtk case, this is for things like avahi, gtk-vnc, caribou, libcanberra - things that provide a library or module that links against given gtk SLOT or implements a gtk module for that SLOT with the given IUSE. The remainder concerns only applications, as we don't like to use the same flag name for different concepts (library support vs application toolkit version choice), and USE="gtk" might be something we could perhaps get rid of, in favor of moving gtk2 libraries to IUSE="gtk2" and application choice to IUSE="gui" or the proposed GUI USE_EXPAND. use.desc: gui - Enable an optional GUI use.desc/gui.desc: athena - Choose the MIT Athena widget set gtk - Build a <pkg>x11-libs/gtk+</pkg> based GUI motif - Build a <x11-libs/motif> toolkit based GUI sdl - ... qt4 - Build a Qt4 toolkit based GUI qt5 - Build a Qt5 toolkit based GUI wxwidgets - Build a wxWidgets based GUI Xaw3d - Build a 3d athena widget set based GUI Many of current IUSE=gtk should move to IUSE=gui when it's about application GUIs. Some of IUSE=gtk will move to version specific IUSE=gtk2 and IUSE=gtk3 when it's about libraries. Not sure if anything will remain then. If it does, we'll need to think about it then, or figure it out of the masses of IUSE=gtk users beforehand. An old mapping was partially conducted a while ago on https://docs.goog le.com/spreadsheets/d/19sJuupspkY65FrU6b4U7gEWKiOgFGQwyXYdPCAvPqBo/edit #gid=0 In no circumstance is a REQUIRED_USE or an equivalent pkg_pretend limitation allowed when dealing with gui USE_EXPAND. - A package has optional support for a GUI, written in any GUI toolkit (but only one) -- IUSE="gui" and depend and build against the toolkit it uses. No toolkit specific USE_EXPAND should exist, as there's nothing to choose. Example: wicd. USE="gui" shall build the gtk based GUI - A package has optional support for a GUI, and that GUI can be chosen to be either gtk, qt4 or qt5 based, but only one of them -- IUSE="gui gui_gtk gui_qt4 gui_qt5". If user has USE="gui" disabled for the package, don't build any GUI. If it's enabled, have a maintainer chosen preferred order of toolkit to use, then choose whichever highest priority toolkit flag is enabled by user. If no supported toolkit flag is chosen, choose the highest priority one. Example: ??? - A package has a required GUI, but the GUI can be chosen to be either gtk, qt4 or qt5 based, but only one of them -- Same as previous, but no IUSE="gui" as a GUI is not optional Example: ??? - A package has optional GUI frontends in a way that multiple can be built and shipped at once. -- IUSE="gui" to have any GUI at all, if user hasn't it set, gui_* values do not matter - no GUI will be built at all. If user has USE="gui" set, all of the user enabled gui_* frontends will be built. If user has no gui_* enabled at all that this package implements, but USE="gui" is set, then a maintainer chosen first choice GUI is built. Example: transmission with IUSE="gui gui_gtk gui_qt" - Same case as previous, but some toolkits are exclusive, e.g one can build both a gtk frontend and a qt frontend, but not both qt4 and qt5 frontend. -- Same USE="gui" behaviour. If multiple exclusive flags are set, they have an independent priority order, similar to when only one can be built. So with GUI="gtk qt4 qt5", a gtk and a qt5 frontend would be built when both qt4 and qt5 can't be. To choose qt4 frontend, qt5 has to be disabled by user for this package. - Same as prior 2 cases but a GUI is not optional (e.g lack of frontend doesn't make sense) -- Same, but no IUSE="gui" Suggestions for users approach of the GUI="" setting in make.conf: * If you don't care which toolkit is used, but rather would have the preferred one chosen for you, don't set it at all, but keep it empty. Do set USE="gui" if you want a GUI for where it's optional. * If you strongly prefer a given toolkit or toolkits, set that/those in GUI="..."; it will be then chosen whenever possible (if multiple, a maintainer decided preference will be chosen, if only one toolkit frontend is available; otherwise all of them will be built). If the program doesn't support building against that toolkit, a different choice will automatically be made for you. If you want to tweak that choice (e.g it pulls in a toolkit you want to avoid completely), tweak the flags in package.use Raised concerns: * With gui as the USE_EXPAND, a GUI variable from make.conf will apparently be exported to all ebuild environments, even if not used, which might mean something for the build environment of the given package. * The dependency conditionals can get very messy with the priority list of toolkits Possible future improvement ideas: * Make USE_EXPAND able to declare a priority list at ebuild level with some syntax, so that it would express it once, and then unset the GUI choices that won't be used due to exclusivety for DEPEND parsing, to make this clearer. Then this priority can be expressed to the user somehow by PM. * Record the filtered choices made in VDB (or similar for other PMs), so the package manager would know which toolkit was actually chosen. * Allow giving a priority for users as well, e.g GUI="1|gtk 2|qt4 2|qt5" or some different syntax, which would then influence that priority when possible (in this case prioritize gtk over others, and qt4/qt5 have equal priority over that - as they are equal, the ebuild priority between them counts instead). This might then morph it into something other than USE_EXPAND in terminology, but till then, USE_EXPAND allows us to group the choices into one logical block.
