Bug 251842 - math/eigen3 FULL option pulls in openblas which conflicts with ATLAS, please add BLAS selection
Summary: math/eigen3 FULL option pulls in openblas which conflicts with ATLAS, please ...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-kde (Team)
Keywords: buildisok
Depends on:
Reported: 2020-12-14 18:52 UTC by alt2600
Modified: 2020-12-31 23:54 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (kde)

makefile patch (1.19 KB, patch)
2020-12-14 18:52 UTC, alt2600
no flags Details | Diff
proposed complete Makefile (1.57 KB, text/plain)
2020-12-14 18:53 UTC, alt2600
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description alt2600 2020-12-14 18:52:25 UTC
Created attachment 220552 [details]
makefile patch

With the new FULL option for the port blas was locked to openblas. Its not clear how this is using blas given its a template library. Not sure why openblas was selected instead of the default netlib "reference" port as this doesn't conflict with other blas libraries.

I copied in code from a new dependancy superlu to allow the builder to select the blas library of their choosing with some edits. I correlated this to the FindBLAS.cmake file in this port to name the vendor codes appropriately. This selection of blas to use is only set when FULL is set. Not sure this is the most elegant, but the code does allow selection of the blas option and builds fine. kdenlive seems to work fine with the movit built against my atlas version of eigen3.

I've attached the patch, I will also post the full Makefile. Its possible it may be better to use Reference instead of openblas by default. Even with this set I'm thinking the cmake script will locate what it finds in the system, but I haven't checked this. I believe this was the old manner this built.
Comment 1 alt2600 2020-12-14 18:53:12 UTC
Created attachment 220553 [details]
proposed complete Makefile
Comment 2 Automation User 2020-12-29 05:56:42 UTC
Build and package info is available at https://gitlab.com/swills/freebsd-ports/pipelines/235238381
Comment 3 Alex S 2020-12-29 16:38:09 UTC
This is somewhat similar to the bug 251939.
Comment 4 alt2600 2020-12-31 23:28:38 UTC
(In reply to Alex S from comment #3)
In that we have no knobs to select the dependencies of FULL when the build system of the port itself has these built into the CMAKE scripts, then yes. But fundamentally this is different. In the Bug you cite people are asking for a lite slave port to be created, even in that case FULL would use openblas instead of freebsd's default BLAS library of netlib, which means people who use ATLAS cannot use this port at all without similar local edits to their port tree. Also I suggest the port use the default BLAS pack instead of an optional one if selection of BLAS is rejected by the maintainer so at the very least it will not conflict with optional BLAS libraries folks may be using. In the bug you cite, no where has a proposed patch been made to implement selection of these dependencies, they just want an alternate binary (slave port) to become part of the pkg repo that doesn't pull in these dependencies.

My bug and patch implement selection of the BLAS library to choose when the FULL build option has been selected, and is the Makefile I'm running in my tree to build ultimately kdenlive, the only ultimate port I have with this dependency.

the major issue with FULL common to both these bugs is turning full off does not necessarily disable the CMAKE build of the port to find the libraries on your system and include them as dependencies anyway, they might just not be tracked properly as a dependency. I believe the comments on implementing FULL in the first place was to fix that issue, by forcing the libraries that will be detected to be automatically dependencies. Not everyone use poudriere or binary packages, to have clean stripped build systems. For folks using eigen3 strictly for math it makes sense they may not want to have GL dependencies, and might want to select a preferred BLAS as well as other knobs. Fundamentally there should be knobs, and unless absolutely required, defaults should not use optional Ports libraries instead of the default libraries if there are no knobs, especially when doing so causes conflicts.
Comment 5 Alex S 2020-12-31 23:37:11 UTC
(In reply to alt2600 from comment #4)

> In the Bug you cite people are asking for a lite slave port to be created

Well, that person submitted bug report on my advice, which basically stated "this is dumb and should be corrected". I don't know where this misunderstanding comes from. I've been very clear, the option serves no purpose and shouldn't be there at all. It's completely ridiculous I even need to explain this.
Comment 6 alt2600 2020-12-31 23:54:37 UTC
(In reply to Alex S from comment #5)
fair enough, it is just a template library, none of the template files seem to make any references to any external libraries that are being pulled in. I guess I missed the fundamental reasoning of your comment here. They only make sense if you want to build tests, or perhaps the full eigen3 BLAS implementation, which this port most certainly doesn't do or support.

CPP is not my forte, especially with template programming, so I wasn't sure if somewhere the templates libraries were tweaked to utilize external libraries, so I was solely focused on getting the package installed so I could move on the the ports i wanted to use. I will certainly concede your point.