sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

dev-manual, profile-manual: changed "plugin" to "plug-in" 

Changed all these occurrances throughout the manual set so
they are consistent.  The only ones left are now in pathnames
or UI things where they need to stay that way.

(From yocto-docs rev: 1b77f34b7b6983f7d7e680cd9fd6a714c00ba8f8)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2013-09-19 12:05:15 -07:00 committed by Richard Purdie
parent d3bf6bd677
commit 9fbaa9b9ec
2 changed files with 75 additions and 75 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
documentation/dev-manual/dev-manual-common-tasks.xml
View File

@ -270,7 +270,7 @@
the layer to which it originally belongs.
If this is the case, you need to address that deficiency
instead of overlaying the include file.
For example, consider how support plugins for the Qt 4
For example, consider how support plug-ins for the Qt 4
database are configured.
The Source Directory does not have MySQL or PostgreSQL.
However, OpenEmbedded's layer <filename>meta-oe</filename>
@ -278,11 +278,11 @@
Consequently, <filename>meta-oe</filename> uses
<filename>.bbappend</filename> files to modify the
<filename>QT_SQL_DRIVER_FLAGS</filename> variable to
enable the appropriate plugins.
enable the appropriate plug-ins.
This variable was added to the <filename>qt4.inc</filename>
include file in the Source Directory specifically to allow
the <filename>meta-oe</filename> layer to be able to control
which plugins are built.
which plug-ins are built.
</para>
</section>
@ -3393,7 +3393,7 @@
<para>
Many pieces of software split functionality into optional
modules (or plugins) and the plugins that are built
modules (or plug-ins) and the plug-ins that are built
might depend on configuration options.
To avoid having to duplicate the logic that determines what
modules are available in your recipe or to avoid having

4
documentation/profile-manual/profile-manual-usage.xml
View File

@ -3094,7 +3094,7 @@
If you already have an LTTng trace on a remote target and
would like to view it in Eclipse on the host, you can easily
copy it from the target to the host and import it into
Eclipse to view it using the LTTng Eclipse plugin already
Eclipse to view it using the LTTng Eclipse plug-in already
bundled in the Eclipse (Juno SR1 or greater).
</para>
@ -3172,7 +3172,7 @@
<para>
You can access extensive help information on how to use
the LTTng plugin to search and analyze captured traces via
the LTTng plug-in to search and analyze captured traces via
the Eclipse help system:
<literallayout class='monospaced'>
Help | Help Contents | LTTng Plug-in User Guide