#43704: unify the use of +threads as a variant name -------------------------------------------------+------------------------- Reporter: mojca@… | Owner: macports- Type: enhancement | tickets@… Priority: Normal | Status: new Component: ports | Milestone: Resolution: | Version: Port: boost cherokee gauche hdf5 hdf5-18 | Keywords: raxml | -------------------------------------------------+------------------------- Changes (by mf2k@…): * cc: mmoll@… (added) * port: boost cherokee gauche hdf5 raxml => boost cherokee gauche hdf5 hdf5-18 raxml Old description:
From #43593: would it make sense to unify the variant names used across different ports?
Here are some variant names from different ports:
{{{ boost: variant no_single description {Disable building single- threaded libraries} gauche: variant no_threads { configure.args-delete --enable- threads=pthreads } raxml: variant pthreads conflicts hybrid description {Pthreads implementation} cherokee: variant no_pthread description {Disable threading support}
sbcl: variant threads description {Enable multi-threaded runtime using the Mach pthreads interface.} tcl: variant threads description {add multithreading support} yap: variant threads abinit: variant threads description {Build with support for multi- thread support (openMP)} openmpi: variant threads description {enable threads for MPI applications} wannier90: variant threads description {Build with threaded ATLAS}
hdf5: variant threadsafe description {Enable threadsafety (experimental, fails unit-tests)} }}}
If this doesn't apply to your port (that is: if the keyword `+threads` misses the point – I'm not sure if `+threads` and `+threadsafe` have "compatible" meanings for example), please say so and remove your port from the list of affected ports. But variants like `+no_threads` should certainly be inverted.
New description: From #43593: would it make sense to unify the variant names used across different ports? Here are some variant names from different ports: {{{ boost: variant no_single description {Disable building single- threaded libraries} gauche: variant no_threads { configure.args-delete --enable- threads=pthreads } raxml: variant pthreads conflicts hybrid description {Pthreads implementation} cherokee: variant no_pthread description {Disable threading support} sbcl: variant threads description {Enable multi-threaded runtime using the Mach pthreads interface.} tcl: variant threads description {add multithreading support} yap: variant threads abinit: variant threads description {Build with support for multi- thread support (openMP)} openmpi: variant threads description {enable threads for MPI applications} wannier90: variant threads description {Build with threaded ATLAS} hdf5: variant threadsafe description {Enable threadsafety (experimental, fails unit-tests)} hdf5-18: variant threadsafe description {Enable threadsafety. +threadsafe is EXPERIMENTAL with +cxx, +fortran, or any mpi variant} }}} If this doesn't apply to your port (that is: if the keyword `+threads` misses the point – I'm not sure if `+threads` and `+threadsafe` have "compatible" meanings for example), please say so and remove your port from the list of affected ports. But variants like `+no_threads` should certainly be inverted. -- Comment: Adding hdf5-18 and Cc'ing the maintainer for possible comment. -- Ticket URL: <https://trac.macports.org/ticket/43704#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X