Current version 2.4.2-r2 was released in 2014, has several pending bugs and I think it is safe to say it is fairly broken at this point.
plus ebuild supports only python 2.7
Created attachment 642380 [details] nlopt-2.6.2.ebuild Quick and dirty version bump - works for me
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1c975626cefbea18e1d2e1c1c1bfbedc662b1cda commit 1c975626cefbea18e1d2e1c1c1bfbedc662b1cda Author: Mark Wright <gienah@gentoo.org> AuthorDate: 2020-06-21 04:54:05 +0000 Commit: Mark Wright <gienah@gentoo.org> CommitDate: 2020-06-21 04:54:05 +0000 sci-libs/nlopt: Bump to 2.6.2 Thanks to Marian Kyral for starting work on the ebuild bump. Closes: https://bugs.gentoo.org/724640 Package-Manager: Portage-2.3.101, Repoman-2.3.22 Signed-off-by: Mark Wright <gienah@gentoo.org> sci-libs/nlopt/Manifest | 1 + sci-libs/nlopt/nlopt-2.6.2.ebuild | 95 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 96 insertions(+)
Please close this after cleanup.
Sanity check failed: > sci-libs/nlopt-2.6.2 > depend x86 stable profile default/linux/x86/17.0 (11 total) > dev-python/numpy-python2[-python_single_target_python2_7(-),python_targets_python2_7(-)] > rdepend x86 stable profile default/linux/x86/17.0 (11 total) > dev-python/numpy-python2[-python_single_target_python2_7(-),python_targets_python2_7(-)]
Why don't you just drop python2_7 support? There are no revdeps. This must surely be wrong: > python? ( > ${PYTHON_DEPS} > $(python_gen_cond_dep 'dev-python/numpy-python2[${PYTHON_USEDEP}]' -2) > $(python_gen_cond_dep 'dev-python/numpy[${PYTHON_USEDEP}]' -3) > )
All sanity-check issues have been resolved
Please add arches when ready.
Current ebuild is a rather strange one. * the fetched file is saved as v2.6.2.tar.gz * fortran bindings are not in IUSE and managed (IMHO) weirdly: -DNLOPT_FORTRAN=$(usex test) * unless python is in IUSE, cmake_src_install is not executed: after emerging, there are no include files, no pkgconfig and no cmake files Am I missing something?
(In reply to Michelangelo Scopelliti from comment #9) > Current ebuild is a rather strange one. > > * the fetched file is saved as v2.6.2.tar.gz I'd say you are right that something should be done with this. The usual "-> ${P}.tar.gz". > * fortran bindings are not in IUSE and managed (IMHO) weirdly: > -DNLOPT_FORTRAN=$(usex test) It seems to imply you only need fortran for testing but there is no dependency whatsoever on fortran or eclass inheritance. That is indeed lacking. > * unless python is in IUSE, cmake_src_install is not executed: > after emerging, there are no include files, no pkgconfig and no cmake files > There is no compilation without python either. > Am I missing something? I don't think you do. The ebuild technically works, it just doesn't do what it should :( The design is lacking because you have to interweave properly python-r1 and cmake-utils eclass commands.
(In reply to François Bissey from comment #10) > (In reply to Michelangelo Scopelliti from comment #9) > > * the fetched file is saved as v2.6.2.tar.gz > > I'd say you are right that something should be done with this. The usual "-> > ${P}.tar.gz". Indeed that's a non-starter. Also covered by https://qa-reports.gentoo.org/output/gentoo-ci/output.html#sci-libs/nlopt
There is further confusion because it tries to support static-libs, when doing so is difficult with the current build system. I wouldn't bother unless there is a real need for it, but that adds quite a bit of complexity.
static-libs should be completely dropped from there. If really needed, it must be done with multibuild.eclass.
I would suggest moving the python bindings to their own ebuild. The design of this ebuild becomes way too confusing because of its attempt to do it at the same time. It would work fine with a single python implementation but trying to do several at the same time is just landing you in a bad place scripting wise.
Mark, I suggest you make a GitHub PR with the aforementioned necessary changes and give us a chance to review and help improve the result.
Created attachment 645588 [details] Corrected ebuild proposal I am not a fan of the ebuild I am attaching but it fixes all of the most obvious shortcomings of the previous one. * tarball name: fixed * fortran inheritance: fixed * compile, install and test with or without python: fixed Still problematic: * If multiple pythons are requested, the compile, test and install of the non-python stuff is duplicated. Splitting the python binding would need to skip the non python stuff at install somehow. * Documentation, is there anything we can do to improve on this. Fell free to use this for a PR.
I should say I started from 2.6.2-r1 ebuild in tree, not the one attached to this bug.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=81c90b0e2306772099620a6c0a56d7f991506ad1 commit 81c90b0e2306772099620a6c0a56d7f991506ad1 Author: Mark Wright <gienah@gentoo.org> AuthorDate: 2020-06-22 01:41:27 +0000 Commit: Mark Wright <gienah@gentoo.org> CommitDate: 2020-06-22 01:41:27 +0000 sci-libs/nlopt: Inherit fortran, fix static-libs logic. Fix QA bad filename: [ v2.6.2.tar.gz ], thanks to Michelangelo Scopelliti for reporting. inherit fortran-2, thanks to Michelangelo Scopelliti and François Bissey for reporting. Put back the logic I incorrectly removed when adding support for USE=static-libs for building stuff when USE=-python. Thanks to Michelangelo Scopelliti, François Bissey and Andreas Sturmlechner for helping. Co-Authored-By: François Bissey <frp.bissey@gmail.com> Bug: https://bugs.gentoo.org/724640 Package-Manager: Portage-2.3.101, Repoman-2.3.22 Signed-off-by: Mark Wright <gienah@gentoo.org> sci-libs/nlopt/Manifest | 2 +- sci-libs/nlopt/nlopt-2.6.2-r1.ebuild | 12 ++++++++++-- sci-libs/nlopt/nlopt-2.6.2.ebuild | 12 ++++++++++-- 3 files changed, 21 insertions(+), 5 deletions(-)
You missed my line FORTRAN_NEEDED="test" under PYTHON_COMPAT. This means that fortran dependencies are only pulled by the fortran-2 eclass if the useflag test is on. https://devmanual.gentoo.org/eclass-reference/fortran-2.eclass/index.html But it is much better already :) at least it is functional.
Do the test run properly when configured without python? run_in_build_dir is also provided by the cmake eclass and by default with cmake, the build is out of source in a separate build_dir. If you don't use cmake_src_test you should run with `run_in_build_dir` I think.
(In reply to François Bissey from comment #19) > You missed my line > FORTRAN_NEEDED="test" > under PYTHON_COMPAT. This means that fortran dependencies are only pulled by > the fortran-2 eclass if the useflag test is on. > https://devmanual.gentoo.org/eclass-reference/fortran-2.eclass/index.html Upstream give a short description of their NLOPT_FORTRAN cmake flag on line 42 of: /var/tmp/portage/sci-libs/nlopt-2.6.2/work/nlopt-2.6.2/CMakeLists.txt option (NLOPT_FORTRAN "enable fortran tests" OFF) It always compiles Fortran code along with C and C++ code. > But it is much better already :) at least it is functional. That's good. Sorry I broke it while I was trying to fix the static-libs late at night while tired and getting over the flu. (In reply to François Bissey from comment #20) > Do the test run properly when configured without python? Yes they do run properly when I tried it. > run_in_build_dir is > also provided by the cmake eclass and by default with cmake, the build is > out of source in a separate build_dir. If you don't use cmake_src_test you > should run with `run_in_build_dir` I think. I like the suggestion, however its uneccessary as I guess by design /usr/portage/eclass/cmake.eclass is already using an out of source build in the same default directory as if 'run_in_build_dir' was added to it, this is on line 29: : ${BUILD_DIR:=${WORKDIR}/${P}_build} I will try to see if I can build the HTML documentation.
> (In reply to François Bissey from comment #20) > > Do the test run properly when configured without python? > > Yes they do run properly when I tried it. > > > run_in_build_dir is > > also provided by the cmake eclass and by default with cmake, the build is > > out of source in a separate build_dir. If you don't use cmake_src_test you > > should run with `run_in_build_dir` I think. > > I like the suggestion, however its uneccessary as I guess by design > /usr/portage/eclass/cmake.eclass is already using an out of source build > in the same default directory as if 'run_in_build_dir' was added to it, this > is on line 29: > > : ${BUILD_DIR:=${WORKDIR}/${P}_build} > I am not sure you get my point. But it's OK, your function `do_test` has `cd ${BUILD_DIR}/test` near the top, which means that all instances of `run_in_build_dir` in src_test are actually redundant.
Is the latest version ready for stabilisation then?
I'll guess so.
amd64 stable
x86 stable. Closing.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b9ce0bb059a90dc796135b4fee18c1044d338775 commit b9ce0bb059a90dc796135b4fee18c1044d338775 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-07-21 09:42:03 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-07-21 09:42:03 +0000 sci-libs/nlopt: Drop 2.4.2-r2 and 2.6.2 (r0) Closes: https://bugs.gentoo.org/724640 Package-Manager: Portage-3.0.0, Repoman-2.3.23 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> sci-libs/nlopt/Manifest | 1 - sci-libs/nlopt/nlopt-2.4.2-r2.ebuild | 118 ----------------------------------- sci-libs/nlopt/nlopt-2.6.2.ebuild | 110 -------------------------------- 3 files changed, 229 deletions(-)
