Passive->active:
s/will explain/explains/

Passive->active:
s/will cause/causes/

s/the following/these/

Looks like a tab hiding in there before "If".

"above" seems unnecessary.

If the destination is in the same document, just use <xref linkend="gnome-components"/>.
If that really is a link to another document, it needs more of a URL.

"tricks" implies these are not standard methods. How about "techniques"?

s/your own/new/

s/dependacies/dependencies/

Add a comma after "applications".

Isn't it Qt (lowercase "T"), and an application name? That would be <application>Qt</application>.

Address comment, or remove. Ideally, add a link to the place that describes how Qt applications are handled.

s/components/component/
s/arguments/arguments,/
s/it listed/they are listed/

<literal> around the parentheses.

For the second sentence, just

The first is the default.

s/used/shown/
s/adding to/adding to both/

s/dependency/dependencies/

Need a blank line between thead and tbody elements.

Need a blank line between row elements. Also below.

Probably easier to read with spaces after the commas. (Also in later entries.)

(both, build, run)

Capitalize:

<title>GNOME Macro Components</title>

There can be more than one thing meant by "configure", but I think this the individual port's configure target. So use <buildtarget> tags on it.

I would change the tense of all of these sentences to say that it was used for that, but not have any in the present tense.

<entry>Deprecated, do not use.  Was used to check if a
component was installed.  This was used for ports that did not have
<literal>--enable</literal>/<literal>--disable</literal>
switches for their configure script.  But the building of
parts of a port without an implicit request is
discouraged.</entry>

It would be good to mention why this is no longer needed (like the next entry) or what to use in its place.

I think I get what you mean, but I think I need some time before I can get my head around how to do this.

Missing an "is":
s/first the/first is the/

It might be that there is just no need for it any more. But when you tell the reader "don't do this any more", the natural question they will have is "what should I do instead?"

maybe:

<literal>BUILD</literal>/<literal>LIB</literal>/<literal>RUN</literal>

or:

build-time, run-time, or libraries dependencies

add a tabulation between = and gtk30

The <varname>USE_GNOME</varname> components will automatically add the dependencies they need.

(note that components is plural here)

An xref must be empty, so, remove "the" and the content of the tag, it'll end up looking like: "Please see section x.y.z, <it's title>".
Also, it's linkend not linked.

for an exhaustive list of (full already implies all, and exhaustive is more correct than full)

You should drop the part about bsd.port.options.mk, everything is supposed to be doable after bsd.port.options.mk, just say cannot be set after including bsd.port.pre.mk.

missing something like is at the end.

You should use an <xref linkend="blah"/> to reference the next section, if they get moved around, it'll still be correct.

<application>GTK+</application>, <application>Freedesktop</application>

Same here, an xref must be empty, you should remove the xref, and replace acronym with application, I think.

they are listed between parenthesis in the

I'm wondering if the Implies column is a good idea. A port must always list all the components it needs, it must not assume some component will be brought in by some other component, as this can change, and break stuff.

Any reason that is not in the deprecated section below ?

The second is somewhat more readable. That should be

build-time, run-time, or library dependencies

Can eliminate "The" and "will":

<varname>USE_GNOME</varname> components automatically add the dependencies they need.

We can make it simpler and shorter:

Please see <xref linkend="gnome-components"/> for the list of

Nice!

I see your point, I still think it is a good idea. For the reason that you don't have to set glib20 if you have gtk30 already on the list. The users don't know this unless they dive into bsd.gnome.mk. If changes happen, like the recent librsvg2 change, then user needs to be tested anyway. And most of this stuff will not change.

• if the software you're porting only needs gtk30, then it doesn't need to know that gtk30 will bring glib20.
• if the software you're porting needs glib20 and gtk30, then you put both, and the fact that gtk30 also needs glib20 is of no matter, as your software needs it anyway.