Bug 238154 - math/cminpack: Change to a shared libary
Summary: math/cminpack: Change to a shared libary
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Fernando Apesteguía
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2019-05-27 00:21 UTC by Yuri Victorovich
Modified: 2019-05-31 17:44 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (fernape)
koobs: merge-quarterly?


Attachments
patch (1.04 KB, patch)
2019-05-27 00:21 UTC, Yuri Victorovich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer freebsd_triage 2019-05-27 00:21:03 UTC
Created attachment 204633 [details]
patch

The OpenTURNS project fails to find cminpack when it is a static library, but finds it fine when it is a shared library. There's some bug in one of them, it's easier to just have a shared library rather than finding the bug.

Also the openblas dependency was missing - this patch adds it.
Comment 1 Fernando Apesteguía freebsd_committer freebsd_triage 2019-05-27 17:41:22 UTC
(In reply to Yuri Victorovich from comment #0)

Hi Yuri,

I'll test the patch, but out of curiosity: math/openturns does not even declare a dependency on math/cminpack. So why the change?

And how is math/openturns in the tree if it doesn't build in the first time?

Cheers.
Comment 2 Yuri Victorovich freebsd_committer freebsd_triage 2019-05-27 18:03:47 UTC
(In reply to Fernando Apesteguía from comment #1)

> math/openturns does not even declare a dependency on math/cminpack

Yes, its cmake looks for cminpack.


> And how is math/openturns in the tree if it doesn't build in the first time?

cminpack is an optional dependency.
Comment 3 Fernando Apesteguía freebsd_committer freebsd_triage 2019-05-29 17:00:01 UTC
(In reply to Yuri Victorovich from comment #2)

> cminpack is an optional dependency.

I don't see it as a dependency, optional or not. I'm insisting because if I run:

find . -name Makefile -exec grep -H cminpack {} \;

which I do to test ports depending on my ports, I won't find math/openturns. If math/openturns is a user of cminpack, it should record that in its Makefile.
Comment 4 Yuri Victorovich freebsd_committer freebsd_triage 2019-05-29 17:18:42 UTC
(In reply to Fernando Apesteguía from comment #3)

-- The following OPTIONAL packages have been found:

 * BISON (required version >= 2.4)
 * FLEX
 * TBB
 * muParser (required version >= 2.2.3)
 * HMAT (required version >= 1.2)
 * LibXml2
 * Threads
 * Boost (required version >= 1.46)
 * R
 * OPTpp
 * Ceres
 * SWIG (required version >= 2.0.9)
 * PythonInterp
 * PythonLibs (required version == 3.6.8)

-- The following OPTIONAL packages have not been found:

 * CMinpack
Comment 5 Fernando Apesteguía freebsd_committer freebsd_triage 2019-05-29 17:23:02 UTC
(In reply to Yuri Victorovich from comment #4)

I'm assuming that's the output of the _upstream_ Makefile, what I'm talking about is math/openturns/Makefile. There, I don't see the port declaring its dependency on math/cminpack. Or are you talking about a newer version of openturns that didn't hit the tree yet?
Comment 6 Yuri Victorovich freebsd_committer freebsd_triage 2019-05-29 17:26:47 UTC
Dependency check on cminpack fails, because it uses a static library. With cminpack as a shared library it works.

Static libraries should be avoided anyway because the benefit that they provide is only marginal, but they cause problems with binary size, obscured dependencies, etc. portmgr@ also spoke against static libraries, Hence - my patch.
Comment 7 Fernando Apesteguía freebsd_committer freebsd_triage 2019-05-29 17:35:08 UTC
(In reply to Yuri Victorovich from comment #6)

I'm not against shared libraries or in favor of static ones...

My questions is simple: How am I supposed to know that math/openturns depends on math/cminpack (so _I can properly test my updates in order to not break your port_) if when I do "grep cminpack math/openturns/Makefile" I get nothing.

So, are you talking about a new version you are working on? Or does this already happens in the version we already have in the tree?
Comment 8 Yuri Victorovich freebsd_committer freebsd_triage 2019-05-29 18:10:18 UTC
(In reply to Fernando Apesteguía from comment #7)

As far as math/openturns is concerned, I already tested it and it works with this patch. Just believe me. -)
Comment 9 commit-hook freebsd_committer freebsd_triage 2019-05-31 16:13:58 UTC
A commit references this bug:

Author: fernape
Date: Fri May 31 16:13:27 UTC 2019
New revision: 503180
URL: https://svnweb.freebsd.org/changeset/ports/503180

Log:
  math/cminpack: build as a shared library

  This change makes math/openturns able to find cminpack.

  Also add dependency on openblas

  PR:	238154
  Submitted by:	yuri@

Changes:
  head/math/cminpack/Makefile
  head/math/cminpack/pkg-plist
Comment 10 Fernando Apesteguía freebsd_committer freebsd_triage 2019-05-31 16:18:55 UTC
Committed,

Please note that I truly think you missed the point in comment #7: It is not about math/openturns build status NOW, it is about FUTURE changes in math/cminpack that MIGHT break math/openturns just because I have no way to know if math/openturns DEPENDS on math/cminpack (and I mean _automatically_ and not trusting just my memory)

PS: Deliberately leaving maintainer-feedback in '?' state.
Comment 11 Yuri Victorovich freebsd_committer freebsd_triage 2019-05-31 16:35:35 UTC
(In reply to Fernando Apesteguía from comment #10)

This is a problem in OpenTURNS that they have optional dependencies and just ignore them when they are missing. I will create an issue for them, this is the best I can do at the port level.
Comment 12 Yuri Victorovich freebsd_committer freebsd_triage 2019-05-31 17:43:21 UTC
For the record, I asked OpenTURNS to add cmake variables requiring external dependencies to be present: https://github.com/openturns/openturns/issues/1152
Comment 13 Fernando Apesteguía freebsd_committer freebsd_triage 2019-05-31 17:44:15 UTC
(In reply to Yuri Victorovich from comment #12)
Exellent.

Thanks!