Update devel/binutils to 2.33.1 and FLAVORIZED it

[bapt]

Summary

Update binutils to 2.33.1 and use flavors instead of slave ports

[mat]

devel/binutils could use a bit of love wrt https://www.freebsd.org/doc/en/books/porters-handbook/porting-order.html to make it more readable.

devel/avr-gcc/Makefile

19

missing devel/.

devel/binutils/Makefile

36–54

Would you terribly mind having a look at https://www.freebsd.org/doc/en/books/porters-handbook/porting-order.html?

FLAVORS go just after the dependency block.
Also, FLAVOR should be defined as ${FLAVORS:[1]} like everywhere else?

devel/sope4/Makefile

35

?

[bapt]

Address @mat points

[jhb]

Heh, I had thought about just doing this for the ones used by xtoolchain, but this looks more complete.

One thing that might really be nice would be to have an easy way to have multiple PLIST files so that one could have something like:

PLIST_FILES= ${.CURDIR}/pkg-plist ${.CURDIR}/pkg-plist.${TARGETARCH}

And put "common" files in pkg-plist and ARCH-specific files in the sub-plists rather than duplicating lots of plist content. For freebsd6-gcc I used a unified plist with PLIST_SUB's for ARCH-specific files, but having a nice way to have pkg-plist.${FOO} in addition to pkg-plist would be nicer IMO.

One thing to consider is that this doesn't fix all the places that have dependencies like all the devel/<arch>-gcc ports, etc.

[bapt]

In D22258#486560, @jhb wrote:

Heh, I had thought about just doing this for the ones used by xtoolchain, but this looks more complete.

One thing that might really be nice would be to have an easy way to have multiple PLIST files so that one could have something like:

PLIST_FILES= ${.CURDIR}/pkg-plist ${.CURDIR}/pkg-plist.${TARGETARCH}

And put "common" files in pkg-plist and ARCH-specific files in the sub-plists rather than duplicating lots of plist content. For freebsd6-gcc I used a unified plist with PLIST_SUB's for ARCH-specific files, but having a nice way to have pkg-plist.${FOO} in addition to pkg-plist would be nicer IMO.

Agreed on that, but that requires some work on the framework which I will probably do later, if the use case becomes common ;)

One thing to consider is that this doesn't fix all the places that have dependencies like all the devel/<arch>-gcc ports, etc.

hum did I miss a place? as far as grep tells me, I should have addressed everything. Anyway I requested an exp-run, we will know quickly.

[jhb]

In D22258#486564, @bapt wrote:

In D22258#486560, @jhb wrote:

Heh, I had thought about just doing this for the ones used by xtoolchain, but this looks more complete.

One thing that might really be nice would be to have an easy way to have multiple PLIST files so that one could have something like:

PLIST_FILES= ${.CURDIR}/pkg-plist ${.CURDIR}/pkg-plist.${TARGETARCH}

And put "common" files in pkg-plist and ARCH-specific files in the sub-plists rather than duplicating lots of plist content. For freebsd6-gcc I used a unified plist with PLIST_SUB's for ARCH-specific files, but having a nice way to have pkg-plist.${FOO} in addition to pkg-plist would be nicer IMO.

Agreed on that, but that requires some work on the framework which I will probably do later, if the use case becomes common ;)

I would use it in freebsd-gcc*, base/binutils, and base/gcc* at least. :)

One thing to consider is that this doesn't fix all the places that have dependencies like all the devel/<arch>-gcc ports, etc.

hum did I miss a place? as far as grep tells me, I should have addressed everything. Anyway I requested an exp-run, we will know quickly.

Oh, I guess it was just powerpc64-gcc/Makefile that had to be updated.

I'm fine with this one landing first and then updating my freebsd6-gcc one. Should be a tiny update to that.

[jhb]

devel/binutils/Makefile

17

base/binutils depends on this I think?

OTOH, it might be that base/binutils should not be a slave of this port anymore. There are many special cases in devel/binutils/Makefile that are just for base/binutils.

[bapt]

devel/binutils/Makefile

17

I do have another patch do decouple base/binutils from this, because it starts to become too complicated to handle both.
My only plan is to keep the patch directory in sync between both. And for sure I will update base/binutils before committing that.

[bapt]

Address exp-run issues