Bug 227372

Summary: [exp-run] Update devel/cmake to 3.11.0
Product: Ports & Packages Reporter: Adriaan de Groot <adridg>
Component: Individual Port(s)Assignee: Port Management Team <portmgr>
Status: Closed FIXED    
Severity: Affects Only Me CC: adridg, antoine, jcfyecrayz, kde, tcberner, yasu
Priority: --- Flags: bugzilla: maintainer-feedback? (kde)
adridg: exp-run?
Version: Latest   
Hardware: Any   
OS: Any   
URL: https://reviews.freebsd.org/D14506
Attachments:
Description Flags
Patch against ports r463565
none
Build log of poudriere none

Description Adriaan de Groot freebsd_committer freebsd_triage 2018-04-08 14:12:49 UTC 
Created attachment 192339 [details]
Patch against ports r463565

kde@ would like to ask for an exp-run to upgrade cmake to 3.11.0.

The patch is attached, and can also be found in Phab review D14506
Comment 5 commit-hook freebsd_committer freebsd_triage 2018-04-15 21:44:02 UTC 
A commit references this bug:

Author: adridg
Date: Sun Apr 15 21:43:58 UTC 2018
New revision: 467437
URL: https://svnweb.freebsd.org/changeset/ports/467437

Log:
  Update CMake to 3.11.0. Thanks to antoine@ for the exp-run.

  In the run-up to this commit, many other ports were pre-emptively fixed.
  The only issue still known is math/kig, which had a build failure in
  the exp-run, but which isn't reproducible across multiple 11.1 {i386,amd64}
  machines and poudriere builds. We've decided to forge ahead.

  The new CMake version:
   - drops FreeBSD patches that have been incorporated upstream,
   - re-shuffles patches to FindQt4, since upstream has made some changes
     which break FindQt4 in new ways on FreeBSD (while fixing the old ones),
   - has new patches to make OpenMP and BLAS findable on FreeBSD,
   - drops ports libarchive in favor of the version in base, to avoid
     overlinking for the pkg(8) support in CPack (this makes portlint
     complain, and we have decided to ignore it).

  PR:		227372 226959 223678
  Approved by:	tcberner (mentor)
  Differential Revision:	https://reviews.freebsd.org/D14506

Changes:
  head/devel/cmake/Makefile
  head/devel/cmake/distinfo
  head/devel/cmake/files/InitialCache.cmake
  head/devel/cmake/files/patch-Modules_FindBLAS.cmake
  head/devel/cmake/files/patch-Modules_FindImageMagick.cmake
  head/devel/cmake/files/patch-Modules_FindOpenMP.cmake
  head/devel/cmake/files/patch-Modules_FindQt4.cmake
  head/devel/cmake/files/patch-Modules_FindwxWidgets.cmake
  head/devel/cmake/files/patch-Modules_FindwxWindows.cmake
  head/devel/cmake/files/patch-git_3f4924-boost_1.66
  head/devel/cmake/pkg-plist
  head/devel/cmake-doc/Makefile
  head/devel/cmake-doc/pkg-plist
  head/devel/cmake-gui/Makefile
Comment 6 Yasuhiro Kimura freebsd_committer freebsd_triage 2018-04-16 01:34:07 UTC 
Created attachment 192542 [details]
Build log of poudriere

(In reply to commit-hook from comment #5)

After this commit build fails in stage-qa phase.
Attached file is build log of poudriere.

Build conditions:
Host: 11.1-RELEASE-p9 amd64
Jail: 11.1-RELEASE-p9 amd64
Ports tree: ports r467439
Comment 7 Adriaan de Groot freebsd_committer freebsd_triage 2018-04-16 10:18:47 UTC 
(In reply to Yasuhiro KIMURA from comment #6)

Yes, that is exactly the overlinking problem we have chosen to ignore. We do not want to explicitly make CMake depend on pkg, because pkg and pkg-devel conflict with each other. We do not want to add USES=libarchive, because pkg links to base libarchive (.so.6) while ports provides .so.13 (or later).
Comment 8 Yasuhiro Kimura freebsd_committer freebsd_triage 2018-04-16 13:28:26 UTC 
(In reply to Adriaan de Groot from comment #7)

OK, I understand what you think is problem.
But as a simple fact, currently this port cannot be build with poudriere.
And as far as I tried same error happens on real 11.1-RELEASE environment.
So would you mind my asking under what conditions this port currently can be build successfully?
Comment 9 John Hein 2018-04-16 15:19:22 UTC 
(In reply to Yasuhiro KIMURA from comment #8)
'stage-qa' fails here for me as well on 10/stable...

Error: Bad linking on libarchive.so.6 for  please add USES=libarchive
Error: /usr/local/bin/ccmake is linked to /usr/local/lib/libarchive.so.13 from archivers/libarchive but it is not declared as a dependency
Warning: you need USES+=libarchive
Error: /usr/local/bin/cpack is linked to /usr/local/lib/libpkg.so.4 from ports-mgmt/pkg but it is not declared as a dependency
Warning: you need LIB_DEPENDS+=libpkg.so:ports-mgmt/pkg
Comment 10 John Hein 2018-04-16 15:22:12 UTC 
Perhaps Mk/Uses/libarchive.mk could grow support for base libarchive (similar to Uses/iconv.mk).
Comment 11 John Hein 2018-04-16 15:32:27 UTC 
I will add that if the libarchive port is installed, cmake will like with that version (/usr/local/lib/libarchive.so.13).  But the libarchive dependency is now not flagged as a dependency.  Then if the user later removes the libarchive package, cmake will break:

Shared object "libarchive.so.13" not found, required by "ccmake"

If you want to disable linking with the port version of libarchive, you need to be more explicit (either in devel/cmake and/or adding the option in Mk/Uses/libarchive.mk).

The 'pkg' dependency will have a similar problem.
Comment 12 John Hein 2018-04-16 15:34:16 UTC 
(In reply to John Hein from comment #11)
I'm surprised an exp-run doesn't catch these Q/A problems.  Or are they ignored?
Comment 13 Adriaan de Groot freebsd_committer freebsd_triage 2018-04-16 22:03:18 UTC 
With all these considerations -- we will be updating the CMake port shortly (tuesday or wednesday) to make pkg optional *or* to make stage-qa accept the port. It depends on what is technically feasible; goal is that a poudriere build with -t (which runs stage-qa) will actually succeed.
Comment 14 Mathieu Arnold freebsd_committer freebsd_triage 2018-04-17 11:40:56 UTC 
exp-runs never run with bulk -t as there are so many ports that will fail with it.
Comment 15 John Hein 2018-04-17 13:51:14 UTC 
(In reply to Mathieu Arnold from comment #14)
Understood re: no bulk -t for exp-runs.  Thanks.
Comment 16 John Hein 2018-04-17 13:56:35 UTC 
(In reply to Adriaan de Groot from comment #13)
Maybe there's a way to really force cmake/ccmake/etc. to link with /usr/lib/libarchive.so.  Clearly, the InitialCache.cmake addition to try to force /usr/lib/libarchive.so is not working somehow.  After 'configure' there are a few link.txt files that have '-larchive' instead of /usr/lib/libarchive.so.  I haven't tracked down why yet.  If we solve that, then we don't need to disable any Q/A tests (which seem to be helpful and doing the right thing).  Nor should we have to make pkg optional.  Anyone have an idea where the -larchive comes from (despite specifying LibArchive_LIBRARY=/usr/lib/libarchive.so)?
Comment 17 commit-hook freebsd_committer freebsd_triage 2018-04-17 18:00:57 UTC 
A commit references this bug:

Author: adridg
Date: Tue Apr 17 18:00:40 UTC 2018
New revision: 467620
URL: https://svnweb.freebsd.org/changeset/ports/467620

Log:
  Fix stage-qa problems with devel/cmake

  Linking to base libarchive is disallowed by stage-qa, so restore
  USES=libarchive (to avoid the bundled libarchive and to link to
  ports libarchive) and drop the pkg(8) generator for CPack, since
  libpkg in turn pulls in base libarchive.

  PR:		227372
  Approved by:	tcberner (mentor, implicit)

Changes:
  head/devel/cmake/Makefile
  head/devel/cmake/files/InitialCache.cmake
Comment 18 Adriaan de Groot freebsd_committer freebsd_triage 2018-04-18 06:48:00 UTC 
(In reply to Yasuhiro KIMURA from comment #6)

Thank you for your earlier comments. Could you please confirm that CMake 3.11.0_1 (latest ports) does build in your poudriere setup?
Comment 19 Yasuhiro Kimura freebsd_committer freebsd_triage 2018-04-18 08:18:55 UTC 
(In reply to Adriaan de Groot from comment #18)

I checked with ports r467657 and confirmed this port can be build successfuly on both poudriere and real environment. Thank you for fixing the problem.
Comment 20 Raphael Kubo da Costa freebsd_committer freebsd_triage 2018-04-29 10:52:44 UTC 
Can we close this one?
Comment 21 Yasuhiro Kimura freebsd_committer freebsd_triage 2018-04-29 10:55:04 UTC 
(In reply to Raphael Kubo da Costa from comment #20)

Yes, I agree to close this bug report.
Comment 22 Tobias C. Berner freebsd_committer freebsd_triage 2018-04-29 10:55:26 UTC 
Yes. There is a new one for 3.11.1 here: #227824, which should also address #227573.