Created attachment 220552 [details]
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.
Created attachment 220553 [details]
proposed complete Makefile
Build and package info is available at https://gitlab.com/swills/freebsd-ports/pipelines/235238381
This is somewhat similar to the bug 251939.
(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.
(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.
(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.
A commit in branch main references this bug:
Author: Adriaan de Groot <adridg@FreeBSD.org>
AuthorDate: 2021-09-07 08:58:27 +0000
Commit: Adriaan de Groot <adridg@FreeBSD.org>
CommitDate: 2021-09-07 21:28:08 +0000
math/eigen3: massage OPTIONs
Existing OPTIONs pull in too many dependencies -- Eigen is a template
library and doesn't **need** any of the libs -- and are overly-specific,
like requiring a particular BLAS implementation.
PR: 257321 251842
Reported by: email@example.com
UPDATING | 18 ++++++++++++++++++
math/eigen3/Makefile | 16 ++++++++++------
2 files changed, 28 insertions(+), 6 deletions(-)
I've tried to take suggestions and changes from both PRs into account and, overall, do something useful with the dependencies. I realise now I forgot to do a PORTREVISION bump, and I suppose we could chase whether BLAS needs to be a default option or not. As a non-user of Eigen it's kind of hard to tell what are useful settings here.