[MacPorts] #43704: unify the use of +threads as a variant name

[MacPorts]

#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