In D20885#452741, @linimon wrote:

In D20885#452740, @mat wrote:

As you added a list, maybe add another point about excluding -msse* extensions

I do intend to add more information to this section based on the rework I am doing to accomodate "powerpc64 no longer implies gcc by default". Fortunately most of those do not require a policy decision, but this one does, so I would like to address it separately. Thanks.

As you added a list, maybe add another point about excluding -msse* extensions from any non amd64 arch as it limits where the software can run on i386, and it breaks on other architectures. (grep'ing for sse in the tree, it seems there also is -mfpmath=sse.)

This is quite similar to D8943.

• feedback.

• Add a note in the Qt chapter.

• Rework.

I don't think the <sect2> are needed, the section is not long, and having examples in a separate subsection does not make a lot of sense (to me at least).

make sure the commit message contains every bit of information that was requested in the PR.

Ok, so, I am not going to go through the whole patch again. Only use USES=go:no_targets when the targets are added by the framework, like with cmake.
If the port has a do-build and a do-install target use USES=go, do not add the :no_targets.

In D20724#449167, @zeising wrote:

In D20724#449059, @mat wrote:

I think you are trying to put really too much magic in xorg-cat.

I am merely replicating the functionality that was in bsd.xorg.mk. All of this is in the old bsd.xorg.mk, and there it works. bsd.xorg.mk is only pulled in from bsd.ports.mk if USE_XORG or XORG_CAT is defined, perhaps it is better left this way, rather than converted to USES?

In D20732#448849, @zeising wrote:

I thought the porter's handbook was for external facing things, so to speak. xorg-cat is meant to be only for xorg ports (ports coming from freedesktop.org), and not for general consumption. I have no problem adding it to the handbook, but since other similar things, such as qt-dist.mk, wasn't documented, I thought this was the way to do it. the previous XORG_CAT isn't documented anywhere, as far as I can tell.

I think you are trying to put really too much magic in xorg-cat.

In D20732#448816, @zeising wrote:

In D20732#448815, @mat wrote:

Could you also add documentation for USES=xorg-cat?

I purposefully omitted it, since it is supposed to be internal to xorg ports, not used by other ports, similar to qt-dist.mk.

Is there any port that would USES=go:run ? Because there is none in the other review, and we really do not like to add code that is never used.

This probably needs an exp-run to make sure nothing breaks.

if make index passes, it's ok by me.

I don't understand the change you made to the pkg-message file. I asked to choose either install or upgrade, looking at this, it is only needed the first time you install the port, so the second bit about upgrade is not required.

Could you also add documentation for USES=xorg-cat?

Also, to be consistent with the rest of the Ports framework, do not quote words in tests.

Also, could you please run both new mk files through Tools/scripts/indent_make_if.pl so that the indentations is consistent with other files in that directory?

The sanity bits need to stay, we don't remove them.

rebase

rebase

Do include the explanation in the commit message.

• Be consistent.

https://www.freebsd.org/doc/en/articles/committers-guide/ports.html#ports-qa-misc-updated-distfile

The source files should not be put in the "files" directory, if one day you need to add support files, like *.in files, it will clutter everything. It would be preferable to put them in a src directory.

In D20698#447450, @adamw wrote:

In D20698#447300, @mat wrote:

Then if the MFH line contains anything else than a branch name, say:

MFH: 2019Q2 (security update blanket approval)

There is no need to send an email because it will already have gotten committed.

That's what the above patch does.

In D20394#447314, @imp wrote:

In D20394#444447, @adamw wrote:

In D20394#444436, @mat wrote:

In D20394#441905, @kmoore wrote:

Anyway, open to suggestions on where to next take this conversation to reach some consensus around these topics.

The consensus is that this does not belong in the ports tree.

I want to piggyback on this. The ports tree needs to be about ports, and it just doesn't make sense to mix src and ports in the same tree.
If I were you(pl.), I'd make a new tree for building src packages. It can piggyback ports/Mk, and with the addition of some src-tree Mk/Uses files you should be in business. The process and resources are identical, but it should live in its own tree.
To build pkgs out of src, I would have suggested calling it /usr/pkgsrc but that name means something else :-)

I'm having trouble understanding how this is materially different than all the kmod ports relying on /usr/src for their builds, and that's not verified at all either. Also, in the future, we may have a src git repo, and we're looking at having signed commits so we'll know that a tree has integrity.