id summary reporter owner description type status priority milestone component version resolution keywords cc port 43704 unify the use of +threads as a variant name mojca macports-tickets@… "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." enhancement new Normal ports mattoates@… mf2k mamoll ryandesign michaelld boost cherokee gauche hdf5 raxml