- https://blog.kitware.com/cmake-3-10-1-available-for-download/
- flang support
- changes to automoc policies
- support for FreeBSD package generation with CPack
Necessary fixes to other ports:
- cad/openvsp make search for libxml explicit
- math/scalapack force C compiler to be compatible with mpi
- deskutils/kdepim4 fix incorrect sources list
- www/qt5-webkit fix incorrect sources list
Thanks to Antoine for the multiple exp-runs.
PR: 223872
Approved by: tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D13210
Update CMake to latest upstream release. This is a minor bug-fix release --
the changelog suggests mostly polishing applied to the FindBoost module.
Thanks to antoine@ for the exp-run.
PR: 222878
Approved by: rakuco (mentor)
Differential Revision: https://reviews.freebsd.org/D12604
This includes the upstream patches for the new Boost version (PR 222207, r450301).
Thanks to antoine@ for the exp-run.
PR: 222513
Approved by: rakuco (mentor), tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D12427
Due to an upstream commit [2] we need now to pass
CMAKE_INSTALL_MANDIR:PATH="share/man" in the
devel/llvm-* ports, and fix the plist of net/remmina.
Further add an upstream patch to math/plplot to
fix the build with 3.7.1.
[1] https://cmake.org/cmake/help/v3.7/release/3.7.html
[2] https://github.com/kitware/cmake/commit/956054
PR: 214975
Approved by: rakuco (mentor)
Exp-run by: antoine
Plasma5 ports
At the moment KDE ports use bsd.kde4.mk to handle their dependencies. When
working on the ports for KDE Frameworks and Plasma5 it seemed to be more
reasonable to create a new kde.mk instead of adding an bsd.kde5.mk.
The kde.mk in this review is a stripped down version of the one we are using in
the KDE Test repositories plasma5 branch [1] to only contain the parts relevant
to the current KDE4 ports in the portstree [2].
Changes to the KDE Ports needed by this:
Replace USE_KDE4 by USE_KDE [3]
Add USES=kde:4 [4]
[1] http://src.mouf.net/area51/view/branches/plasma5/KDE/Mk/Uses/kde.mk
[2] The version in the plasma5 branch also handles frameworks/plasma5 and
handles MASTER_SITES via a KDE_DIST variable similar to bsd.qt.mk for Qt
Ports -- I chose to leave this out for now, as the diff is already large
enough.
[3] I chose USE_KDE instead of USE_KDE4, USE_KDE5, USE_KDEX as the version we
want is already specified as argument to kde:<arg>
[4] For KDE Frameworks and Plasma5 ports this would be kde:5
PR: 210667
Approved by: portmgr, mat (mentor), rakuco (mentor)
Reviewed by: mat, rakuco
Differential Revision: https://reviews.freebsd.org/D6961
Announcement: https://blog.kitware.com/cmake-3-5-0-available-for-download/
Most ports have already been fixed for this update, but science/orthanc was
included in this commit because I am not entirely sure the changes in it work
with CMake < 3.5.0. In short, FindDCMTK.cmake was rewritten and the way orthanc
uses the DCMTK variables was incompatible with the use upstream intended.
PR: 208033
This is a small bug fix release mostly targeting Windows 10 targets.
Release announcement: http://www.kitware.com/blog/home/post/1036
PR: 206519
Submitted by: Tobias Berner <tcberner@gmail.com>
At least lang/gcc (4.8) and later were known to be broken like this:
/usr/ports/devel/cmake/work/cmake-3.4.0/Source/cmArchiveWrite.h:93:23: error: 'mode_t' has not been declared
void SetPermissions(mode_t permissions_)
^
/usr/ports/devel/cmake/work/cmake-3.4.0/Source/cmArchiveWrite.h:106:27: error: 'mode_t' has not been declared
void SetPermissionsMask(mode_t permissionsMask_)
^
/usr/ports/devel/cmake/work/cmake-3.4.0/Source/cmArchiveWrite.h:179:26: error: 'mode_t' was not declared in this scope
cmArchiveWriteOptional<mode_t> Permissions;
^
/usr/ports/devel/cmake/work/cmake-3.4.0/Source/cmArchiveWrite.h:179:32: error: template argument 1 is invalid
cmArchiveWriteOptional<mode_t> Permissions;
^
/usr/ports/devel/cmake/work/cmake-3.4.0/Source/cmArchiveWrite.h:180:26: error: 'mode_t' was not declared in this scope
cmArchiveWriteOptional<mode_t> PermissionsMask;
^
/usr/ports/devel/cmake/work/cmake-3.4.0/Source/cmArchiveWrite.h:180:32: error: template argument 1 is invalid
cmArchiveWriteOptional<mode_t> PermissionsMask;
^
This was introduced in CMake 3.4.0, so there is no need for an MFH request.
PR: 204921
runetype.h uses _Thread_local, and if we pass -std=c11 or -std=gnu11 to GCC
the header expects it to be supported as part of the language and does not
make it a typedef or something else.
Since GCC only started supporting _Thread_local with the 4.9 series,
building CMake with, say, lang/gcc (which is 4.8) fails:
/usr/include/runetype.h:92:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'const'
/usr/include/runetype.h: In function '__getCurrentRuneLocale':
/usr/include/runetype.h:96:6: error: '_ThreadRuneLocale' undeclared (first use in this function)
/usr/include/runetype.h:96:6: note: each undeclared identifier is reported only once for each function it appears in
The upstream patch adds a test for _Thread_local and uses C99 instead of C11
if it fails.
PR: 203066
Release notes for the 3.3 series:
http://www.cmake.org/cmake/help/v3.3/release/3.3.html
This update took longer than expected because of a behavior change in CMake:
now calls to find_library(), find_path() etc will take the $PATH environment
variable into consideration, which in practice means that it will prefer
libraries in base instead of those in ports when both versions are available.
r395972 is an example of the groundwork that had to be done before landing this
patch.
- deskutils/owncloudclient: When OpenSSL from ports is to be used, make sure to
pass ${LOCALBASE} as $CMAKE_PREFIX_PATH, otherwise it will use the version in
base (see above) and fail on 9.x.
- math/cgal: Import upstream patch to fix the configuration process with CMake
3.3.x.
PR: 202516
The build was failing with, for example, lang/gcc48:
In file included from /usr/ports/devel/cmake/work/cmake-3.2.3/Source/cmGlobalNinjaGenerator.cxx:14:0:
/usr/ports/devel/cmake/work/cmake-3.2.3/Source/cmGeneratorExpressionEvaluationFile.h:39:64: error: 'mode_t' has not been declared
std::map<std::string, std::string> &outputFiles, mode_t perm);
Do it so that we can hardcode these variables to point to base's liblzma,
otherwise the liblzma.so installed by archivers/lzmalib will be chosen if
present and the configuration process will fail.
This is done only so that `make configure' works, as liblzma is only used if
we build CMake's bundled libarchive.
MFH: 2015Q2
The py-sphinx system brings in a number of dependencies that wouldn't
otherwise be necessary for cmake. The MANPAGES option defaults to on,
so the main pkg won't change.
PR: 193259
Approved by: kde (makc)
- Normalize the ImageMagick library name so it stays the same regardless of
what the 16-bit and HDRI option are set to [1]. Teach cmake to look for
the new name. Bump ports that link to the libraries due to this.
- As a result do away with the "HALFSUPPORTED" option block, and list
16-bit and HDRI with the other options.
- ImageMagick ships a basic SVG plugin when not using librsvg2 for SVG
support. This basic SVG plugin needs libxml2 to work [2]. Make libxml2
a mandatory dependency (instead of only when the SVG option was selected).
- Don't touch .keep files in the modules directory, there files there so
it useless.
PR: 194949 [1]
PR: 195227 [2]
Requested by: many [1]
Submitted by: software-freebsd@interfasys.ch [2]
Upstream release notes:
http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html
Notable changes on the packaging side:
* devel/cmake does not need USE_OPENSSL=yes anymore. In fact, it has not
needed it since r366996, when we stopped building CMake's bundled copies
of curl, libarchive & friends (curl was the only consumer of OpenSSL in
CMake).
* Likewise, we do not need to set CMAKE_USE_OPENSSL in InitialCache.cmake
anymore.
* On FreeBSD < 10, devel/cmake and devel/cmake-gui now depend on
archivers/libarchive because the libarchive version in base is too old and
does not contain some functions that CMake uses.
PR: 196367
r375798 made the OPTIONS prompt show up on every build because
bsd.port.pre.mk was being included too early. Move the inclusion down one
section.
PR: 196374
Submitted by: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
We have the same problem described in https://reviews.freebsd.org/D875:
> bsd.ports.mk sets STRIP= after all Uses files have been processed
> initially. If you have WITH_DEBUG=yes set, cmake's INSTALL_TARGET has been
> set already to install/strip, before STRIP is reset.
In other words, INSTALL_TARGET would always be set to "install/strip"
even when WITH_DEBUG was set.
Since we do not use USES=cmake here the fix (check for WITH_DEBUG besides
evaluating STRIP) needs to be duplicated in the Makefile.
This is a much smaller update than the previous one, and the only change
worth mentioning on the ports side is that devel/cmake-gui now has
USES=desktop-file-utils because it installs a .desktop file.
PR: 193691
`cmake --help-command' and `cmake --help-policies', which were just
erroring out or not printing anything.
Modules/ and Templates/ are still installed by devel/cmake-modules.
Reported by gahr@.
- Pass --parallel to CMake's bootstrap script to parallelize the initial
part of its build process.
The 3.0 series is an incremental improvement over the previous 2.8 series
despite the major version number change. A list of important changes is
available at http://www.cmake.org/cmake/help/v3.0/release/3.0.0.html
On the porting side
* The minimum FreeBSD release we have to support in the ports tree is now
recent enough that ports/168671 can finally be committed: instead of
building and using CMake's own copies of bzip2, curl, expat, libarchive,
liblzma and zlib, we use the versions in ports and/or the base system.
* CMake's documentation system has been changed and vastly improved at the
cost of now depending on Sphinx. We still generate only man pages, but can
start generating the HTML documentation in the future if desired.
* devel/cmake-gui now uses Qt5 instead of Qt4 and does not needlessly build
the ncurses UI that is installed by devel/cmake itself.
* CMake commit 3816cd2 fixes a longstanding issue in the detection of the
Python interpreter and its libraries, but requires us to revert a
workaround for that in Mk/Uses/python.mk itself, effectively reverting
the patch introduced by ports/168159.
* Similarly, a few ports had to be fixed manually due to CMake being
stricter when parsing some files or the ports detecting Python the wrong
way. Fortunately, they all had been fixed upstream so I just grabbed the
appropriate commits and pointed to them in the patches.
science/gnudatalanguage had to have its PORTREVISION bumped because
switching to USES=cmake:outsource removed a few files from the plist that
were not supposed to have been installed in the first place.
PR: 168671
PR: 192644
