Page MenuHomeFreeBSD
Differential D13384 Diff 36305 audio/GxSwitchlessWah-lv2/Makefile

Changeset View

Standalone View

View Options

audio/GxSwitchlessWah-lv2/Makefile

  • This file was added.
PropertyOld ValueNew Value
svn:eol-stylenullnative
\ No newline at end of property
svn:keywordsnullFreeBSD=%H
\ No newline at end of property
svn:mime-typenulltext/plain
\ No newline at end of property
# $FreeBSD$
PORTNAME= GxSwitchlessWah
DISTVERSION= g20171206
CATEGORIES= audio
PKGNAMESUFFIX= -lv2
MAINTAINER= yuri@FreeBSD.org
COMMENT= Analog wah emulation with switchless activation
LICENSE= GPLv3
LICENSE_FILE= ${WRKSRC}/LICENSE
BUILD_DEPENDS= lv2>0:audio/lv2
USES= gmake localbase
USE_GITHUB= yes
GH_ACCOUNT= brummer10
tcbernerUnsubmitted
Done
Inline Actions

^portlint suggests sorting these

Also if you take a look at
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-order.html#porting-order-portname
it should appear before the dependency block

tcberner: ^portlint suggests sorting these Also if you take a look at https://www.freebsd.org/doc/en_US.
GH_PROJECT= ${PORTNAME}.lv2
GH_TAGNAME= 6977568
PLIST_FILES= lib/lv2/GxSwitchlessWah.lv2/gx_switchless_wah.so \
lib/lv2/GxSwitchlessWah.lv2/gx_switchless_wah.ttl \
lib/lv2/GxSwitchlessWah.lv2/manifest.ttl
post-install:
matUnsubmitted
Done
Inline Actions

What's wrong with supporting more i386 architectures, and arm like I showed you to?

mat: What's wrong with supporting more i386 architectures, and arm like I showed you to?
@${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/lv2/GxSwitchlessWah.lv2/gx_switchless_wah.so
.include <bsd.port.mk>
matUnsubmitted
Done
Inline Actions

Back to this, it does not make much sense.

All amd64 processors support SSE2 at the minimum. It makes no sense to select VFPV3 on any arch other than armv7...

Sorry about suggesting options, it was a wrong idea too. This should be architecture dependent.

SSE_FLAGS_i386="-msse -mfpmath=sse"
SSE_FLAGS_amd64="-msse2 -mfpmath=sse"
SSE_FLAGS_armv6="-march=armv7 -mfpu=vfpv3"

MAKE_ARGS=  SSE_FLAGS=${SSE_FLAGS_${ARCH}}
mat: Back to this, it does not make much sense. All amd64 processors support SSE2 at the minimum.
yuriAuthorUnsubmitted
Done
Inline Actions

There can be variability in SSE support. On Intel CPUs SSE1, SSE2, SSE3, SSE4.1, SSE4.2. Additionally, AMD has SSE4a.

Ideally, the port can have all these SSE-flavors. I was really expecting that the FLAVORS feature could solve this, but it really didn't.

Now, in this case, IMO options should be defined, but some should be limited by architecture.

yuri: There can be variability in SSE support. On Intel CPUs SSE1, SSE2, SSE3, SSE4.1, SSE4.2.
matUnsubmitted
Done
Inline Actions

What we have to support is oldest possible versions, so if SSE is required, SSE on i386, SSE2 on amd64, and the thing that was there for arm. I doubt using more recent versions will change many things.

mat: What we have to support is oldest possible versions, so if SSE is **required**, SSE on i386…
yuriAuthorUnsubmitted
Done
Inline Actions

I doubt using more recent versions will change many things.

There are projects that heavily depend on SIMD. One such project is ray tracing app http://www.ospray.org. It runs 10 times faster when SSE4 is available. I will commit the port for it.

Another project is devel/libsimdpp. It makes it easy to use SIMD, and will automatically adjust to the current level of SIMD. On SIMD-heavy code you will see dramatic differences in runtimes.

FreeBSD as it is doesn't support SIMD well. Simple SSE option doesn't do. SIMD level is like an extension of ${ARCH}, adding a degree of freedom within an architecture. It's like an extra-flavor: One machine needs devel/my-package@simd4.2, and another - devel/my-package@simd2. Ideally, package manager should install the version that corresponds to the SIMD level.

I will adjust this port as you suggested.

yuri: > I doubt using more recent versions will change many things. There are projects that heavily…