Does this look good?

Keep related variables close

Keep USE_* sorted alphabetically

In D16662#365037, @danfe wrote:

Whoops, sorry, I didn't know you've been working on an update. DOXYGEN option is still missing though.

Updated by @danfe in r479514

Remove redundant SUB_FILES

switch back to PORTVERSION

In D17019#363958, @egypcio_googlemail.com wrote:

In D17019#363901, @ndowens_yahoo.com wrote:

In D17019#363374, @fernape wrote:

The port is amd64 only because it depends on devel/gnu-efi that is 64 bit only. That's at least on FreeBSD because the upstream project does not say they don't support ia32 (in fact, according to the Makefile, they do).

The override ARCHpart is because $ARCH is "amd64" in FreeBSD but the Makefile expects to check against "x86_64" as it is often reported in Linux.

I got gnu-efi to build on my 12-i386 poudriere jail
Though have to play with plist because the names will change according to arch

Got rid of USE_GCC line as well

should we try to change the port til this point, or create an equivalent version for i386?

In D17019#363901, @ndowens_yahoo.com wrote:

In D17019#363374, @fernape wrote:

The port is amd64 only because it depends on devel/gnu-efi that is 64 bit only. That's at least on FreeBSD because the upstream project does not say they don't support ia32 (in fact, according to the Makefile, they do).

The override ARCHpart is because $ARCH is "amd64" in FreeBSD but the Makefile expects to check against "x86_64" as it is often reported in Linux.

I got gnu-efi to build on my 12-i386 poudriere jail
Though have to play with plist because the names will change according to arch

Got rid of USE_GCC line as well

In D17019#363810, @tcberner wrote:

In D17019#363374, @fernape wrote:

The port is amd64 only because it depends on devel/gnu-efi that is 64 bit only. That's at least on FreeBSD because the upstream project does not say they don't support ia32 (in fact, according to the Makefile, they do).

The override ARCHpart is because $ARCH is "amd64" in FreeBSD but the Makefile expects to check against "x86_64" as it is often reported in Linux.

Yes, what I meant is, $(ARCH)=amd64 should always be true when building the port, as it is only for ARCH=amd64. So you could simply just unconditionally override it with x86_64, no?

Already updated by @swills

In D16954#363817, @tcberner wrote:

Sorry, @swills already updated it in the meantime in Ports r479003

Move NO_ARCH and NO_BUILD with the section of the rest of variables

Correcting ONLY_FOR_ARCHS_REASON message.

The port is amd64 only because it depends on devel/gnu-efi that is 64 bit only. That's at least on FreeBSD because the upstream project does not say they don't support ia32 (in fact, according to the Makefile, they do).

Add ONLY_FOR_ARCHS_REASON

Remove double USE_GITHUB

Fix icons installation.

Does this one look reasonable?

In D16954#362358, @sunpoet wrote:

In D16954#362244, @fernape wrote:

In D16954#362233, @sunpoet wrote:

I see no need to bump PORTREVISION for dependent ports.

.so library changes version:

in pkg-plist:

lib/libparserutils.so.%%VERSION%%

 # pkg info -l -F libparserutils-0.2.4.txz | grep so
        /usr/local/lib/libparserutils.so
        /usr/local/lib/libparserutils.so.0
        /usr/local/lib/libparserutils.so.0.2.4
root@10_4amd64-default:/wrkdirs/usr/ports/devel/libparserutils/work/pkg #

If the shlib is changed (e.g. from libparserutils.so.0 to libparserutils.so.1), you'll have to bump PORTREVISION of dependent ports.
It tells everyone to "rebuild dependent ports" to link against the new one.

But not in this case.

No matter it is libparserutils.so.0.2.4 or libparserutils.so.0.20.40, the linker still uses /usr/local/lib/libparserutils.so.0 before and after this update.
Nothing is changed.
There's no need to bump/rebuild dependent ports.

Remove the very last piece of comments in the Makefile

In D16954#362233, @sunpoet wrote:

I see no need to bump PORTREVISION for dependent ports.

Remove comments.

In D16956#361982, @tcberner wrote:

Please check that the documentation of the dependent port still builds -- if so it looks good to me (also implicitely) :).

Replace unnecessary += operator

Add missing entry in devel/Makefile

Simplify doxygen files generation.

In D16662#361092, @mat wrote:

In D16662#361023, @fernape wrote:

I don't like duplicating the logic of post-patch-{DOCS,DOXYGEN}-off. Is it preferred to add a normal .if?

You don't need to have a post-patch-DOXYGEN-off, only the post-patch-DOCS-off one is required. Because DOXYGEN_IMPLIES=DOCS.

DOCS: off
DOXYGEN: on

You cannot have DOCS disabled if DOXYGEN is enabled. Because DOXYGEN_IMPLIES=DOCS.

Remove post-patch-DOXYGEN-off.

Fix the port for the whole life cycle of 12-CURRENT.

Fixing DOCS option handling.

In D16909#360481, @tcberner wrote:

^^ I would say, we trust you enough to add that 's' to http implicitely (also other changes to pkg-descr :))

In D16908#360484, @tcberner wrote:

Fails to build for me (r337738):

In file included from os_freebsd.cpp:45:
./atacmds.h:96:9: warning: 'ATA_WRITE_LOG_EXT' macro redefined [-Wmacro-redefined]
#define ATA_WRITE_LOG_EXT               0x3F
        ^
/usr/include/sys/ata.h:387:9: note: previous definition is here
#define ATA_WRITE_LOG_EXT               0x3f
        ^
os_freebsd.cpp:526:10: error: no member named 'opc' in 'nvme_command'
  pt.cmd.opc = in.opcode;
  ~~~~~~ ^
1 warning and 1 error generated.

In D16747#359413, @tcberner wrote:

Good job, working on that :)

I would use the contents of
https://github.com/hills/xosview/commit/0b4861c9fed2dc8450edf2dff7988ebd784a520b.patch
as the patch file (you only need to fix the git-prefix stuff) -- if it applies :) -- otherwise, I would inclulde the link to the pull request at the top of the patch.

If the git-patch works, you could also name it something like patch-git_0b4861c -- that way its obvious that the patch is most likely a temporary thing.

Add git pull request link to the patch.

Removing unnecessary include from Makefile

Add DOXYGEN option instead of DOCS.

In D16662#359378, @tcberner wrote:

You still need to address the DOCS changes requested by mat.

In D16778#359430, @tcberner wrote:

Looks good to me.

Don't flatten hierarchy.

catch up with upstream: update to 1.5.5

Adding depending ports to the review.

Remove change of PKGNAMESUFFIX

In D16704#355411, @tcberner wrote:

I don't think the version bumps are required -- or did the so-ver change?

In D16710#355410, @tcberner wrote:

Is there a fix for current in the works?

Remove INSTALL_ICONS since this is not a gnome port

Is this snippet valid?

• Remove ${WRKSRC} from PYTHON_BINARY_ALIAS
• Remove python_CMD
• Update to 1.5.4