lang/gforth: Fix couple portlint items, add localbase to USES

[ultima]

Summary

• Bump revision
• Move ffcall from RUN_DEPENDS --> LIB_DEPENDS, links to two libs
• Added license, and license file
• Move USES to comply with PHB/portlint
• Add localbase, remove CPPFLAGS+ and LIBS+
• Removed append flag on CONFIGURE_ENV, MAKE_ENV, these are not necessary
• Unsilenced docs install

Reviewed by\: lifanov (mentor), matthew (mentor), johans (maintainer)
Approved by\: lifanov (mentor), matthew (mentor), johans (maintainer), blanket approval(proper use case?)
Differential Revision\: https://reviews.freebsd.org/DXXXXX

While checking the ffcall --> libffcall, I noticed some items on this port that could be fixed.

Test Plan

portlint:
WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make SVN happy.
WARN: Makefile: new ports should not set PORTREVISION.
0 fatal errors and 2 warnings found.

poudriere:
103i386
103amd64
110i386
110amd64
12i386
12amd64

[ultima]

lang/gforth/Makefile

26–27

The append flag maybe removable here, not positive. I don't see these entry in 12.8/12.9 so I think it is fine yes?

[mat]

The patch does not seem to change at all, the only differences are comments, so I would tend to say don't commit that bit.

lang/gforth/Makefile

26–27

The only variables that need to be appendables are the ones one would set in make.conf to globally tune his system, so, CFLAGS, CXXFLAGS, and such. All variables that are from the ports framework should not. (Unless master/slave port configuration, ymmv.)

[ultima]

• Removed patch regen
• Removed append flag on CONFIGURE_ENV, MAKE_ENV

[lifanov]

Add a note that you are also unsilencing an install command (which is good).
I don't think this qualifies for any blanket approvals and even then,
you would typically list either a person(s) or a blanket approval, not both.

[matthew]

Hmmm... this looks to have fallen between the cracks. Are you waiting on anything for committing this? It's already approved.

[ultima]

Yeah this is @johans's port, I was hoping he would take a look before commit, but it has been some time. Is it okay to commit with timeout without bugzilla PR open?

[matthew]

It would be better to have a PR to document a maintainer timeout, but I don't see why an open review shouldn't count as well.

Did you try e-mailing him directly? Some people have been known to filter out phabricator e-mails, so he might not know this is even here...

[ultima]

In D11766#250138, @matthew wrote:

It would be better to have a PR to document a maintainer timeout, but I don't see why an open review shouldn't count as well.

Did you try e-mailing him directly? Some people have been known to filter out phabricator e-mails, so he might not know this is even here...

I did send him an email on 8/2/17, using my @gmail address. Never received a reply.

Hey there,

 I'm contacting you in regards to a patch I created in Phabricator[1].
If you get some time, can you please review it and provide feedback?

Thanks!
Richard Gallamore

[1] https://reviews.freebsd.org/D11766

[matthew]

In that case, I think you can commit and cite maintainer timeout.

[matthew]

In future though, it's best to create a PR.

[ultima]

In D11766#250165, @matthew wrote:

In future though, it's best to create a PR.

Duly noted.

[ultima]

Want to note, had to adapt ffcall from changes in another commit.