Opened 9 years ago
Closed 4 years ago
#48086 closed defect (fixed)
mpich subports use -devel suffix incorrectly
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | eborisch (Eric A. Borisch) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.99 |
Keywords: | Cc: | seanfarley (Sean Farley), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) | |
Port: | mpich |
Description
The mpich port's subports use the -devel suffix incorrectly.
The correct way is that the set of files installed by a port (e.g. mpich-gcc5) is more or less identical to the set of files installed by its -devel counterpart (e.g. mpich-devel-gcc5), and that because the ports install the same files to the same places, the ports are marked as conflicting with one another. The ports are thus interchangeable. For example, a user can deactivate mpich-gcc5 and install mpich-devel-gcc5, and any ports declaring dependencies on mpich-gcc5 using a path:-style dependency will still work. Documentation about -devel ports is pending but see #14540 for a basic description of the expectations.
This is not how the mpich subports currently work. In fact e.g. mpich-gcc5 and mpich-devel-gcc5 do not have any files in common at all, and they can be installed simultaneously. This is specifically not desired in this case, and should be corrected so that -devel and non-devel ports install the same files and conflict.
This also means that the -devel ports should present themselves under the non-devel name in the "port select" interface.
Change History (5)
comment:1 Changed 9 years ago by eborisch (Eric A. Borisch)
comment:2 Changed 9 years ago by seanfarley (Sean Farley)
I'll have to echo what Eric said. As a way forward, we could follow what the gcc / clang ports do: mpich31-gcc49 for mpich 3.1 with gcc 4.9. This would drop the need for the '-devel' suffix entirely.
comment:3 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
There is a pull request that attempts to fix this problem.
comment:4 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Cc: | MarcusCalhoun-Lopez added |
---|
comment:5 Changed 4 years ago by eborisch (Eric A. Borisch)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Dropped -devel.
I will have to think about this more later; I will say that mpich / openmpi are a bit of 'odd ducks' here as they both provide an MPI implementation (compiler wrappers, headers, libraries) that are designed to be interchangeable and share a select interface ('mpi'). As such, it is nice to be able to have multiple flavors available (even installed at the same time) for use outside of macports for testing MPI (for example against current and beta versions of MPICH) software. Ports that use mpi (via the mpi port group) get their compiler values set to the explicit paths -- without requiring select's use; the variants selected determines which one is used.
The original discussion referenced in #14540 was prior to
port select
's inclusion (r44693) -- which may influence the discussion depending on your viewpoint.