An XML element with content looks like this:
<element attribute="value" ...> content </element>
An empty element looks like this:
Element names are case-sensitive.
The "<" and ">" characters need to be replaced with predefined entity tags "<" and ">" when they're not part of an element tag, just like in HTML. However, for whole blocks of text that may contain these special characters, you can enclose them like this:
<![CDATA[ echo foo > output ]]>
If for some reason you need to include the "]]>" string within a CDATA section, you can replace the ">" with its entity tag, just like you'd do outside of a CDATA section (i.e., "]]>").
The XML comment delimiters are "<!--" and "-->".
<encap_profile>
<notes>
<ChangeLog>
<change>
<prereq>
<environment>
<prepare>
<source>
<unpack>
<patch>
<configure>
<build>
<install>
<clean>
<prepackage>
<include_file>
<encapinfo>
The <encap_profile> element supports the following attributes:
Example:
<encap_profile profile_ver="1.0" pkgspec="foo-1.0+1"> ... </encap_profile>
Example:
<notes> These are human-readable notes about a profile. </notes>
The <change> element supports the following attributes:
Example:
<ChangeLog>
<change version="1.0+1">
Fixed a bug in the postinstall script from version 1.0.
</change>
<change version="1.0">
Initial release.
</change>
</ChangeLog>
Example:
Example:
<environment
variable="PATH"
value=":/usr/local/bin"
type="append"
/>
See the ENVIRONMENT VARIABLES section below for more information on how environment variables are set and used.
The prepare action is executed in whatever directory mkencap was invoked in. By default, no prepare commands are executed.
See COMMAND ELEMENTS below for more information on how the <prepare> commands are executed.
Note that the basename of each URL in the list must be the same. No checking is done to ensure that they do not differ, but the results are undefined if they are not identical.
The <source> element contains zero or more of the following elements, which are described below:
Example:
<source url="ftp://ftp.isc.org/isc/bind-8.3.3/bind-src.tar.gz" subdir="bind-8.3.3" use_objdir="no" />
If the <source> element's "use_objdir" attribute is enabled and mkencap's common source directory is set, the unpack action is executed in the common source directory. Otherwise, the unpack action is executed in a subdirectory of the build tree that is named after the pkgspec of the profile.
By default, mkencap will unpack the source archive directly without using any commands specified in the profile. If the <unpack> element is present, mkencap will execute the specified commands instead of unpacking the source archive directly.
See COMMAND ELEMENTS below for more information on how the <unpack> commands are executed.
The content of the <patch> element is the text of the patch file. It should be left empty if the "url" attribute is specified.
Example:
The configuration action is executed in the ${builddir} directory, which is created first if it doesn't exist. The default configuration action is:
${srcdir}/configure \
--prefix="${ENCAP_SOURCE}/${ENCAP_PKGNAME}" \
--sysconfdir="${ENCAP_TARGET}/etc"
Example:
<configure>
xmkmf
${MAKE} includes
</configure>
See COMMAND ELEMENTS below for more information on how the <configure> commands are executed.
The build action is executed in the ${builddir} directory. The default build action is:
Example:
<build type="append">
${MAKE} certificate TYPE=dummy
</build>
See COMMAND ELEMENTS below for more information on how the <build> commands are executed.
The installation action is executed in the ${builddir} directory. The default installation action is:
${MAKE} install sysconfdir="${ENCAP_SOURCE}/${ENCAP_PKGNAME}/etc"
Example:
<install type="append">
cp ssh_prng_cmds ${ENCAP_SOURCE}/${ENCAP_PKGNAME}/ssh_prng_cmds
cp moduli.out ${ENCAP_SOURCE}/${ENCAP_PKGNAME}/moduli
</install>
See COMMAND ELEMENTS below for more information on how the <install> commands are executed.
The clean action is executed in the ${builddir} directory. The default clean action is:
Example:
See COMMAND ELEMENTS below for more information on how the <clean> commands are executed.
The prepackage action is executed in the "${ENCAP_SOURCE}/${ENCAP_PKGNAME}" directory. The default prepackage action is:
find . -name lib -prune -o \
\( -perm -0100 -o -perm -0010 -o -perm -0001 \) \
-type f -print | xargs ${STRIP}
Example:
See COMMAND ELEMENTS below for more information on how the <prepackage> commands are executed.
The content of the <include_file> element is the content of the file to install. Note that a single leading newline will be stripped from the content to aid in readability.
Example:
<include_file name="bin/webconf.in" mode="0755"> (...contents of file...) </include_file>
Note that the following encapinfo fields should not be specified in an <encapinfo> element, since they will be determined dynamically by mkencap:
Example:
<encapinfo> exclude sbin/webconf.in </encapinfo>
First, each command is executed in its own subshell. This means that process-specific actions like setting environment variables or changing directories will not propogate from one command to another. For example, this element does not do what you might think:
<!-- this will NOT work --> <configure> cd src ./configure </configure>
Instead, you need to use something like this:
<!-- this one will work --> <configure><![CDATA[ cd src && ./configure ]]></configure>
Generally, each line is interpretted as a single command. If you need a single command to span multiple lines, you can use a backslash ("\") to escape newlines. For example:
<configure>
${srcdir}/configure \
--prefix="${ENCAP_SOURCE}/${ENCAP_PKGNAME}" \
--sysconfdir="${ENCAP_TARGET}/etc"
</configure>
Finally, mkencap will check the exit code of each command as it is executed. If any command fails, the package creation process will abort immediately. For example:
<build>
${MAKE}
${MAKE} test
</build>
If the "${MAKE}" command fails, mkencap will terminate without executing "${MAKE} test".
The *_MATCH macros check the platform name against a regular expression. The *_EQUAL macros check the platform name against a constant string.
Conditional blocks cannot be nested. For example, this is illegal:
<!-- This is illegal! -->
PLATFORM_IF_EQUAL(rs6000-aix4.3.3)
--with-rundir=/etc
PLATFORM_ELSE
PLATFORM_IF_MATCH(.*linux)
--with-rundir=/var/state
PLATFORM_ELSE
--with-rundir=/var/run
PLATFORM_ENDIF
PLATFORM_ENDIF
Instead, use a conditional block with multuple options:
<!-- This is the right way to do it. --> PLATFORM_IF_EQUAL(rs6000-aix4.3.3) --with-rundir=/etc PLATFORM_ELSE_IF_MATCH(.*linux) --with-rundir=/var/state PLATFORM_ELSE --with-rundir=/var/run PLATFORM_ENDIF
Also, the normal m4 quoting characters are "`" and "'". Since these are frequently used in shell scripts, m4 will be configured to use the strings "<|" and "|>" as quote delimiters instead. You will not normally need to use these delimiters, but if you run into a situation where m4 is expanding something that you do not want it to, you can quote the text that you do not want expanded.
First, mkencap will initialize the environment to the settings found in the /usr/local/etc/mkencap_environment file. Next, mkencap will process any <environment> elements found in the package profile. And finally, mkencap will set the following environment variables:
In addition, the following variables will be set on a per-<source> basis:
All of these environment variables are available for use in shell commands.