Using ninja instead of make (1) can lead to significant speed ups while building.
Therefore switch from having the ninja generator opt-in to having it opt-out.
Previously cmake-ports that wanted to use ninja could set
CMAKE_NINJA=yes
now, ports that do not work with ninja can set
cmake:<existing args>,noninja
Note, that needing this should be an exception and most often points to a broken
cmake of the port.
The ports using cmake were modified
* removed USES=gmake, if ninja is used
* removed MAKE_ARGS, if ninja is used
* added the cmake-argument noninja if necessary
PR: 219629
PR: 213331
Exp-run by: antoine
Reviewed by: rakuco
Differential Revision: https://reviews.freebsd.org/D10748
- Move DISTFILES setting back to master port exclusively as upstream had
used correct (coherent with v1.4) tags for v1.6 this time
- Register mutual port install-time conflict (CONFLICTS_INSTALL)
- Create convenience symlink in `post-extract' rather than `pre-patch',
because `200:dos2unix' bogusly(?) runs before `300:pre-patch'
- Since luxrays' library samples are not built as of r410138, do not try
to patch them (GC currently no-op patches)
- For the same reason, do not request GLUT, GLEW, and execinfo libraries
that were only used when building samples
- Convert FreeImage to an option (mandatory for v1.4) and default to off
materials when using the new LuxCore rendering modes
- Because upstream did not use different tag names for LuxCore and LuxRender
this time, avoid distfile name clash by using .tar.gz format for smaller
distfile (3.1M) and .tar.bz2 for the larger one (28M)
- Ensure that correct build number is reported in the "About" dialog box
- Fix USES and DISTVERSION check for version 1.4 support while I'm here
instructions) use. Particularly, saying "SSE extensions" is superfluous,
as SSE abbreviation itself means "Streaming SIMD Extensions". Correct
way to refer to particular (CPU-agnostic) technology is "SIMD instruction
set", which is not limited to MMX, SSE family, AVX, NEON, etc.
Since "instruction set" looks a bit too formal in the option description,
use more casual and shorter word "instructions".
of -RC versions easier)
- Point MASTER_SITES to fetch distfiles from Bitbucket (src.luxrender.net
redirects there now)
- Add two new USES: `execinfo' and `python:version'; the latter is needed
to avoid build breakage when both Python 2.x and 3.x are installed
- Remove `-pedantic' from CMAKE_CXX_FLAGS to allow building with GCC 4.2
by avoiding "floating constant exceeds range of 'long double'" error
- Reword X11_DESC slightly while here in order to insert space in "Qt 4"
while retaining visual appeal of option description text in the dialog
Instead of defining a variable that is almost always based on CONFIGURE_ENV,
just use CONFIGURE_ENV directly.
This also matches the behavior of other ports that do not use autotools (so
most ports can just worry about CONFIGURE_ENV). Additionally, the fact that
we do not use ?= means we do not have problems if another file in Uses/
needs to set CONFIGURE_ENV (with CMAKE_ENV, the order of the arguments to
USES would matter).
Ports which set CMAKE_ENV have been adjusted accordingly. In most cases,
CMAKE_ENV was just replaced with CONFIGURE_ENV, the exceptions being:
* databases/sqliteman: CMAKE_ENV line removed; setting QMAKESPEC there has
no effect on the build system.
* devel/freeocl: CMAKE_ENV line removed; FREEOCL_CXX_COMPILER is already
retrieved from the CMAKE_CXX_COMPILER variable in the build
system.
* graphics/openimageio: CMAKE_ENV line removed; setting Qt variables there
has no effect on the build system.
Reviewed by: makc
Differential Revision: https://reviews.freebsd.org/D3403
GCC 4.2 in FreeBSD 8.X/9.X base is now too old to compile OpenEXR, so
GCC-based systems will upgrade to the default ports compiler (GCC 4.7
currently.)
Add two patches to OpenEXR to permit building it in a live system with
the older OpenEXR version installed. Bug report filed to upstream Github
at https://github.com/openexr/openexr/issues/130
Couple OpenEXR more tightly to ilmbase and require its exact .so
version.
Add UPDATING note, and bump PORTREVISION of all dependent ports.
Proto-STAGE hugin-devel, and mark it IGNORE because hugin is newer.
Approved by: portmgr (implicit for bumping PORTREVISION on unstaged ports)
linking with code built with our legacy GCC v4.2. Switch to dynamic linking
for Boost libraries as a work-around for infamous "local symbol discarded in
section `.text...' from some_static_lib.a(some_object.o)" errors.
Reported by: pkg-fallout
- Update to 2.0.1
- Change master sites to SAVANNAH
- Change maintainer email to @FreeBSD.org
- Remove conflict with non existent Port
- USES pathfix pkgconfig
- Add executable
- Add DOCS Option
- Support STAGEDIR and add OPTIONS_SUB
- Use pathfix instead of simple patches
- Adjust patches
- Change WWW
graphics/OpenEXR
- Update to 2.0.1
- Change master sites to SAVANNAH
- Change maintainer email to @FreeBSD.org
- Use the new format for LIB_DEPENDS
- USES gmake pathfix pkgconfig
- Add DOCS and EXAMPLES Options
- Support STAGEDIR and add OPTIONS_SUB
- Change REINPLACE_CMD
- Add extra patch for EXAMPLES
- Remove obsolete patches
- Bump dependent ports' revisions
Approved by: pawel / wg (mentors)
It brings bison as a build dependency in case it is set the following way:
USES= bison or USES= bison:build
it brings bison as a run dependency in case it is set the following way:
USES= bison:run
it brings bison both as a run and build dependency in case it the set the following way:
USES= bison:both
While here trim some headers
Convert some USE_GNOME= gnomehack to USES= pathfix
* rephrase Comment field or use port ${COMMENT} if appropriate
* adjust Icon field according to the Desktop Entry Specification
* update Categories field: remove deprecated category Application;
set main category if missing
- Remove indefinite article and/or rephrase COMMENT
Approved by: portmgr (bapt), maintainer silence (12 days)
