Differential D7958 Diff 20578 multimedia/libx264/Makefile

Changeset View

Standalone View

multimedia/libx264/Makefile

	# Created by: Michael Johnson <ahze@FreeBSD.org>			# Created by: Michael Johnson <ahze@FreeBSD.org>
	# $FreeBSD$			# $FreeBSD$
	#			#
	# Updating notes: see multimedia/x264/Makefile.			# Updating notes: see multimedia/x264/Makefile.

	PORTREVISION= 1			PORTREVISION= 0
				koobsUnsubmitted Done Inline Actions I prefer and have always removed PORTREVISION for PORTVERSION updates, but I also like explicit >> implicit (PEP20). brain divides by zero I'll leave this up to you koobs: I prefer and have always removed PORTREVISION for PORTVERSION updates, but I also like explicit…
				jbeichAuthorUnsubmitted Not Done Inline Actions `PORTREVISION=0` serves as a reminder when to bump only master, only slave or both. It also protects against accidental bumps in slaves. However, I'm not trying to become the maintainer here. Removed. jbeich: `PORTREVISION=0` serves as a reminder when to bump only master, only slave or both. It also…
	PKGNAMEPREFIX= lib			PKGNAMEPREFIX= lib
	COMMENT= H.264/MPEG-4 AVC Video Encoding (Library)			COMMENT= H.264/MPEG-4 AVC Video Encoding (Library)
	MASTERDIR= ${.CURDIR}/../x264			MASTERDIR= ${.CURDIR}/../x264
	PLIST= ${.CURDIR}/pkg-plist			PLIST= ${.CURDIR}/pkg-plist

	LIB_DEPENDS= #			LIB_DEPENDS= #
				koobsUnsubmitted Done Inline Actions Can you add a `# comment` above this line to note that this is to null out LIB_DEPENDS from the x264 port without having to use an if/endif block. I couldn't remember why I did this originally, so a note is good for our future selves and other readers. koobs: Can you add a `# comment` above this line to note that this is to null out LIB_DEPENDS from the…
				jbeichAuthorUnsubmitted Not Done Inline Actions According to rP413179 the line is a slave helper to kill `.include <bsd.port.options.mk>`. Ideally, libx264 should have been the master port. Current separation isn't ideal as some libx264-specific stuff is still in x264 port. If you don't mind the risk (and churn) I can swap them but not in this review request. jbeich: According to rP413179 the line is a slave helper to kill `.include <bsd.port.options.mk>`.

	USES= pathfix			USES= pathfix

	OPTIONS_DEFINE= HI10P			OPTIONS_DEFINE= HI10P
	OPTIONS_EXCLUDE= FFMS GPAC LAVF LSMASH SWSCALE			OPTIONS_EXCLUDE= FFMS GPAC LAVF LSMASH SWSCALE
				koobsUnsubmitted Not Done Inline Actions Not 100% on this being a default option (yet)... Is it enabled in a default build? (when just running `./configure`) Was an OpenCL build tested? Test plan doesn't list that specifically Perhaps its worth trialing as a separate port (libx264-opencl) so that we can get it user QA'd "in the field", thoughts? koobs: Not 100% on this being a default option (yet)... - Is it enabled in a default build? (when…
				jbeichAuthorUnsubmitted Not Done Inline Actions OpenCL is enabled upstream by default if the headers are available, before the port explicitly disabled it. Sure. Runtime testing is more tricky as lang/beignet appears to be buggy on drm-next-4.7 while nvidia-driver only supports for OpenCL for linux binaries. Separate ports only make sense for options that cannot be disabled at runtime or carry a lot of bloat. jbeich: - OpenCL is enabled upstream by default if the headers are available, before the port…

	HI10P_DESC= Enable High 10 Profile 10-bit encoding			HI10P_DESC= Enable High 10 Profile 10-bit encoding
	HI10P_CONFIGURE_ON= --bit-depth=10			HI10P_CONFIGURE_ON= --bit-depth=10

				koobsUnsubmitted Done Inline Actions I think they call this (`OPENCL_DESC`) "OpenCL Lookahead", or "Enable OpenCL Lookahead (Hardware Acceleration)" +`LIB_DEPENDS` if either {lib}x264 depend on the library at run time Does `OPENCL_CONFIGURE_ENABLE=opencl` not work? Prefer explicit enable/disable which doesn't rely on upstream defaults, or break if upstream defaults change koobs: I think they call this (`OPENCL_DESC`) "OpenCL Lookahead", or "Enable OpenCL Lookahead…
				jbeichAuthorUnsubmitted Not Done Inline Actions `OPENCL_DESC` was meant to be generic. The next step is moving into Mk/bsd.options.desc.mk. OpenCL isn't limited to GPU (see devel/pocl) while SSE2, AVX, FMA3 would be also hardware acceleration. No! Let dlopen(3) (see 3aa9a67b6d62) take care of choosing OpenCL implementation: ocl-ocd or freeocl. `_ENABLE` does work[1] but applying only to `OPENCL` wouldn't be consistent with x264/Makefile. [1] Build with default options incurs the following warnings but the rest is identical according to diff(1). # multimedia/libx264 Unknown option --enable-asm, ignored Unknown option --disable-debug, ignored Unknown option --enable-opencl, ignored # multimedia/x264 Unknown option --enable-asm, ignored Unknown option --disable-debug, ignored Unknown option --enable-lsmash, ignored jbeich: - `OPENCL_DESC` was meant to be generic. The next step is moving into Mk/bsd.options.desc.mk.
	CONFIGURE_ARGS= \			CONFIGURE_ARGS= \
	--enable-static \			--enable-static \
	--enable-shared \			--enable-shared \
	--disable-cli			--disable-cli

	PATHFIX_MAKEFILEIN= Makefile			PATHFIX_MAKEFILEIN= Makefile

	PLIST_FILES= #			PLIST_FILES= #
	PLIST_SUB+= X264_BUILD=${X264_BUILD}			PLIST_SUB+= X264_BUILD=${X264_BUILD}

	pre-build:			pre-build:

	.include "${MASTERDIR}/Makefile"			.include "${MASTERDIR}/Makefile"