[email protected] writes: > On Thu, Jul 25, 2013 at 9:31 PM, Sean Farley <[email protected]> wrote: >> >> [email protected] writes: >> >>> Again, I haven't scoured the whole thread, but would making sub-ports >>> rather than variants for the different compilers help? The >>> dependent's +gcc44+mpich could require the mpich-gcc44 package, for example. >> >> Not really. It just changes the name to the same problem. > > Except for the fact that you can *depend* on the package (user gets > warnings if they try to install it) but MP will happily let the user > change the variants without warning to the (active) dependents of that > package.
True but I don't think that would buy us anything in this case. The user would still have to manually switch the dependents of the mpi ports. > I personally swap back and forth between variants of mpich > when I'm testing my own MPI code (why, oh why, doesn't clang have > OpenMP support yet?) Because there is almost no benefit for parallel applications? ;-) Really, though, if you're in the domain where OpenMP can help (computation bound, dense linear algebra) then your time is better spent on using CUDA. > Hopefully rev-upgrade will catch that something > has (potentially) gone south, but it won't likely be able to rebuild > things back to their initial state without some hand-holding. That's true. We might have to disable rev-upgrade for ports with multiple compilers? > We could setup the different packages to avoid naming conflicts (much > like gcc44, gcc45) so multiple versions could be installed > side-by-side. An mpich_select could even be put together to redirect > mpicc -> mpicc-gccNN. > > I'm not saying it's necessarily the right idea, I'm just throwing it out > there. It would work for the mpich and openmpi ports but none of their dependents. There would still be a variant problem with the dependents of mpi, e.g. mpich-gcc45 -> hdf5-18+gcc45 -> netcdf+gcc45 -> petsc+gcc45 To help get things moving along, I'd suggest we concentrate on the +gfortran variant (and therefore having mpich / openmpi use 'PortGroup multiplecompilers 1.0'). What would be holding back using the multiplecompilers group with active_variants? _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
