[MacPorts] #47904: cmake @3.2.2_0: variants are a confusing mess
#47904: cmake @3.2.2_0: variants are a confusing mess ----------------------+------------------------- Reporter: larryv@… | Owner: michaelld@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: cmake ----------------------+------------------------- I won’t mince words: `cmake`’s variants make no sense. Half of them only exist if one of the other half are selected. This is not discoverable at all, and I suspect most users only realize that they had a choice after they install `cmake`. ---- Say I want to install CMake. {{{ % port variants cmake cmake has the variants: docs: Build documentation: HTML and manpages gui: Build Qt-based cmake-gui universal: Build for multiple architectures }}} Looks like I have three choices. Cool. I decide to build cmake-gui and the documentation. {{{ % sudo port install cmake +docs +gui ---> Computing dependencies for cmake The following dependencies will be installed: dbus lcms libmng py27-alabaster py27-babel py27-docutils py27-jinja2 py27-pygments py27-roman py27-six py27-snowballstemmer py27-sphinx py27-sphinx_rtd_theme py27-tz python27 qt4-mac sphinx_select Continue? [Y/n]: }}} Eh. Maybe I already have Python 3.4 installed, and I’d rather not install Python 2.7, but it doesn’t look like I have a choice, so I’ll just go with it. But the `+gui` variant seems to require `qt4-mac`. What if I have `qt5-mac` installed? Those conflict, so I guess I’ll just go without the GUI. Except that that wasn’t necessary at all. Turns out I do have choices, but they’re utterly undiscoverable. I’d have to check the list variants //after already selecting a variant//, which is something I never think to do. {{{ % port variants cmake +docs +gui cmake has the variants: +docs: Build documentation: HTML and manpages +gui: Build Qt-based cmake-gui [+]python27: Build documentation using Sphinx from Python 2.7 * conflicts with python34 python34: Build documentation using Sphinx from Python 3.4 * conflicts with python27 [+]qt4: Build Qt GUI using Qt4 * conflicts with qt5 qt5: Build Qt GUI using Qt5 * conflicts with qt4 universal: Build for multiple architectures }}} `cmake` should eliminate this weird two-level thing and instead present all its variants up front. Something like this. {{{ % port variants cmake cmake has the variants: docs_py27: Build HTML docs and manpages using Sphinx from Python 2.7 * conflicts with docs_py34 docs_py34: Build HTML docs and manpages using Sphinx from Python 3.4 * conflicts with docs_py27 gui_qt4: Build cmake-gui with Qt4 * conflicts with gui_qt5 gui_qt5: Build cmake-gui with Qt5 * conflicts with gui_qt4 universal: Build for multiple architectures }}} ---- No patch to offer, I’m afraid. Sorry for the anticlimax. Feel free to let this lie fallow until I whip up something. -- Ticket URL: <https://trac.macports.org/ticket/47904> MacPorts <https://www.macports.org/> Ports system for OS X
#47904: cmake @3.2.2_0: variants are a confusing mess -----------------------+------------------------- Reporter: larryv@… | Owner: michaelld@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: Port: cmake | -----------------------+------------------------- Description changed by larryv@…: Old description:
I won’t mince words: `cmake`’s variants make no sense. Half of them only exist if one of the other half are selected. This is not discoverable at all, and I suspect most users only realize that they had a choice after they install `cmake`.
----
Say I want to install CMake. {{{ % port variants cmake cmake has the variants: docs: Build documentation: HTML and manpages gui: Build Qt-based cmake-gui universal: Build for multiple architectures }}}
Looks like I have three choices. Cool. I decide to build cmake-gui and the documentation. {{{ % sudo port install cmake +docs +gui ---> Computing dependencies for cmake The following dependencies will be installed: dbus lcms libmng py27-alabaster py27-babel py27-docutils py27-jinja2 py27-pygments py27-roman py27-six py27-snowballstemmer py27-sphinx py27-sphinx_rtd_theme py27-tz python27 qt4-mac sphinx_select Continue? [Y/n]: }}}
Eh. Maybe I already have Python 3.4 installed, and I’d rather not install Python 2.7, but it doesn’t look like I have a choice, so I’ll just go with it. But the `+gui` variant seems to require `qt4-mac`. What if I have `qt5-mac` installed? Those conflict, so I guess I’ll just go without the GUI.
Except that that wasn’t necessary at all. Turns out I do have choices, but they’re utterly undiscoverable. I’d have to check the list variants //after already selecting a variant//, which is something I never think to do. {{{ % port variants cmake +docs +gui cmake has the variants: +docs: Build documentation: HTML and manpages +gui: Build Qt-based cmake-gui [+]python27: Build documentation using Sphinx from Python 2.7 * conflicts with python34 python34: Build documentation using Sphinx from Python 3.4 * conflicts with python27 [+]qt4: Build Qt GUI using Qt4 * conflicts with qt5 qt5: Build Qt GUI using Qt5 * conflicts with qt4 universal: Build for multiple architectures }}}
`cmake` should eliminate this weird two-level thing and instead present all its variants up front. Something like this. {{{ % port variants cmake cmake has the variants: docs_py27: Build HTML docs and manpages using Sphinx from Python 2.7 * conflicts with docs_py34 docs_py34: Build HTML docs and manpages using Sphinx from Python 3.4 * conflicts with docs_py27 gui_qt4: Build cmake-gui with Qt4 * conflicts with gui_qt5 gui_qt5: Build cmake-gui with Qt5 * conflicts with gui_qt4 universal: Build for multiple architectures }}}
----
No patch to offer, I’m afraid. Sorry for the anticlimax. Feel free to let this lie fallow until I whip up something.
New description: I won’t mince words: `cmake`’s variants make no sense. Half of them only exist if one of the other half are selected. This is not discoverable at all, and I suspect most users only realize that they had a choice after they install `cmake`. ---- Say I want to install CMake. {{{ % port variants cmake cmake has the variants: docs: Build documentation: HTML and manpages gui: Build Qt-based cmake-gui universal: Build for multiple architectures }}} Looks like I have three choices. Cool. I decide to build cmake-gui and the documentation. {{{ % sudo port install cmake +docs +gui ---> Computing dependencies for cmake The following dependencies will be installed: dbus lcms libmng py27-alabaster py27-babel py27-docutils py27-jinja2 py27-pygments py27-roman py27-six py27-snowballstemmer py27-sphinx py27-sphinx_rtd_theme py27-tz python27 qt4-mac sphinx_select Continue? [Y/n]: }}} Eh. Maybe I already have Python 3.4 installed, and I’d rather not install Python 2.7, but it doesn’t look like I have a choice, so I’ll just go with it. But the `+gui` variant seems to require `qt4-mac`. What if I have `qt5-mac` installed? Those conflict, so I guess I’ll just go without the GUI. Except that that wasn’t necessary at all. Turns out I do have choices, but they’re utterly undiscoverable. I’d have to check the list of variants //after already selecting a variant//, which is something I never think to do. {{{ % port variants cmake +docs +gui cmake has the variants: +docs: Build documentation: HTML and manpages +gui: Build Qt-based cmake-gui [+]python27: Build documentation using Sphinx from Python 2.7 * conflicts with python34 python34: Build documentation using Sphinx from Python 3.4 * conflicts with python27 [+]qt4: Build Qt GUI using Qt4 * conflicts with qt5 qt5: Build Qt GUI using Qt5 * conflicts with qt4 universal: Build for multiple architectures }}} `cmake` should eliminate this weird two-level thing and instead present all its variants up front. Something like this. {{{ % port variants cmake cmake has the variants: docs_py27: Build HTML docs and manpages using Sphinx from Python 2.7 * conflicts with docs_py34 docs_py34: Build HTML docs and manpages using Sphinx from Python 3.4 * conflicts with docs_py27 gui_qt4: Build cmake-gui with Qt4 * conflicts with gui_qt5 gui_qt5: Build cmake-gui with Qt5 * conflicts with gui_qt4 universal: Build for multiple architectures }}} ---- No patch to offer, I’m afraid. Sorry for the anticlimax. Feel free to let this lie fallow until I whip up something. -- -- Ticket URL: <https://trac.macports.org/ticket/47904#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X
#47904: cmake @3.2.2_0: variants are a confusing mess -----------------------+------------------------- Reporter: larryv@… | Owner: michaelld@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: Port: cmake | -----------------------+------------------------- Comment (by michaelld@…): I won't disagree, LV. Is the best solution to make variants depend on other variants? For example, have +qt4 & +qt5 out there by default & neither active by default, and if one of them is selected without +docs then require +docs? That seems a little backhanded, but at least honest in the variants representation for this port. Once I understand the right thing to do, I don't think it'll be difficult doing it. -- Ticket URL: <https://trac.macports.org/ticket/47904#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X
#47904: cmake @3.2.2_0: variants are a confusing mess -----------------------+------------------------- Reporter: larryv@… | Owner: michaelld@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: fixed | Keywords: Port: cmake | -----------------------+------------------------- Changes (by michaelld@…): * status: new => closed * resolution: => fixed Comment: I just pushed r138700, which I think addresses this ticket's issue. I'm closing as fixed; please reopen if you disagree. -- Ticket URL: <https://trac.macports.org/ticket/47904#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts