OpenBLAS and OpenBLAS-devel: unify into one Portfile with subport

[dstrubbe (David Strubbe)]

The OpenBLAS and OpenBLAS-devel Portfiles are very similar. Only a few lines are different. I suggest unifying them into a single port with a subport, to make future maintainence simpler. Though these ports are openmaintainer, I guess this doesn't count as a minor change, so I submit it for the maintainer's consideration. The patch of course would be accompanied by 'svn mv'ing the two files in OpenBLAS-devel/files which are not in OpenBLAS/files and then 'svn rm'ing OpenBLAS-devel.

[NicosPavlov]

I understand the motivation, but the two ports are gradually becoming more different with time, as OpenBLAS is not releasing new versions very often, while several enhancements have been pushed to the repository. This implies that while *-devel is being updated often, bugfixes have to be included in the standard release. I am afraid that having the two of them in the same file could increase the risk of mistakes.

Furthermore, having the two ports separate in a case like this is, at least to my knowledge, standard practice within Macports.

[seanfarley (Sean Farley)]

Replying to nicos@…:

I understand the motivation, but the two ports are gradually becoming more different with time, as OpenBLAS is not releasing new versions very often, while several enhancements have been pushed to the repository. This implies that while *-devel is being updated often, bugfixes have to be included in the standard release. I am afraid that having the two of them in the same file could increase the risk of mistakes.

Furthermore, having the two ports separate in a case like this is, at least to my knowledge, standard practice within Macports.

I would disagree. There is so much code duplication between the two portfiles that it definitely makes sense to combine them. The patches and backports are trivial to separate. Please reconsider.

[dstrubbe (David Strubbe)]

There are example of both patterns: port and port-devel have separate Portfiles, or port-devel as subport in port's Portfile. mpich and openmpi are examples of the latter. So, I think both can be considered standard practices.

My motivation is I want to propose a reform of the treatment of variants, to use the compilers portgroup, and to use the logic that currently changes the meaning of the clang variant to instead set default variants accordingly, which would make things more transparent and controllable to the user. Since this change would apply equally to OpenBLAS and OpenBLAS-devel, it could be applied only once if the Portfiles were merged.

[seanfarley (Sean Farley)]

Yes, what dstrubbe wrote is exactly what I have in mind for most -devel ports. Not only would variants be easier to unify but this could help pave the way for a blas/lapack portgroup.

[petrrr]

What about the julia packaged OpenBlas? Should this be considered as well?

[petrrr]

Cc Me!

[NicosPavlov]

I was not aware that using subports in that case was considered standard. Committed in r141428, with some tweaks to further minimize the differences.

Replying to petr@…:

What about the julia packaged OpenBlas? Should this be considered as well?

Julia is employing a specific interface of OpenBLAS, which is not the default one. It was to my understanding decided to leave the compilation internal for this reason. I had proposed in another ticket to add the option in the Portfile, but it did not lead to anything concrete yet.

I close the ticket as the issue is fixed, but I am still open for discussion about the integration with julia.

[seanfarley (Sean Farley)]

As far as I'm aware, julia uses the 64-bit integer interface for OpenBLAS which would break any port using OpenBLAS today.