On 2016/12/04 22:12, Patrick Wildt wrote:
> If we also add a FLAVOR arm it looks like pkg_add cannot cope with a
> port gaining a flavor without really changing its name.
It can, but you need to tell it via @pkgpath. It's a little more work
but I think it's a more standard way to handle it.
You can do this by adding "@pkgpath devel/arm-none-eabi/binutils" and
"@pkgpath devel/arm-none-eabi/gcc-linaro" to the various PFRAG.arm files,
remove the -Darm / -Daarch64 workaround, and I think also guard against
someone trying FLAVOR="aarch64 arm", e.g.
FLAVOR?= arm
.if "${FLAVOR}" == "aarch64"
CONFIG= aarch64-none-elf
.elif "${FLAVOR}" == "arm"
CONFIG= arm-none-eabi
.else
ERRORS= Fatal: invalid combination of FLAVORs
.endif
Since this changes the pkgpath, dependencies need a bump to chase it -
you're already bumping the various devel/arm-none-eabi so...
sqlite> select * from depends where dependspath like 'devel/arm-none-eabi%'
...> and fullpkgpath not like 'devel/arm-none-eabi%';
sysutils/u-boot|devel/arm-none-eabi/gcc-linaro|||devel/arm-none-eabi/gcc-linaro|B
...sysutils/u-boot is the only thing you'd need to touch.
Minor point but to make it easier to review update diffs in the future,
I would also define a variable for the gcc version, like
GCC_V= 4.9.4
SUBST_VARS+= GCC_V
and use it in PLISTs
-lib/gcc/${CONFIG}/4.9.4/...
+lib/gcc/${CONFIG}/${GCC_V}/...
> FULLPKGNAME seems to be PKGNAME-FLAVOR, which would looks like
> aarch64-none-elf-gcc-linaro-VERSION-aarch64. I overwrite FULLPKGNAME
> so that it stays aarch64-none-elf-gcc-linaro-VERSION.
Yes I think that's the right thing to do.
