cmake @3.2.2_0: variants are a confusing mess

[larryv (Lawrence Velázquez)]

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.

[michaelld (Michael Dickens)]

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.

[michaelld (Michael Dickens)]

I just pushed r138700, which I think addresses this ticket's issue. I'm closing as fixed; please reopen if you disagree.