Ebuild Functions - Revision history

Drobbins: /* Ebuild Functions */

2013-04-05T01:54:49Z

‎Ebuild Functions

216.31.88.193: /* pkg_postrm */

2012-01-12T15:54:34Z

‎pkg_postrm

Drobbins: /* src_install */

2011-07-04T01:44:44Z

‎src_install

Drobbins: Reverted edits by Slashbeast (talk) to last revision by Drobbins

2011-03-08T19:55:46Z

Reverted edits by Slashbeast (talk) to last revision by Drobbins

Slashbeast: /* Extra pre_ and post_ functions */

2011-03-08T17:18:43Z

‎Extra pre_ and post_ functions

Drobbins at 01:24, 18 January 2011

2011-01-18T01:24:05Z

Drobbins: /* Helper Functions */

2011-01-01T19:45:14Z

‎Helper Functions

Drobbins: /* Automatically set libdir = */

2011-01-01T19:31:09Z

‎Automatically set libdir =

Drobbins: /* Helper Functions */

2011-01-01T19:30:48Z

‎Helper Functions

Drobbins at 05:27, 23 December 2010

2010-12-23T05:27:30Z

@@ Line 1: / Line 1: @@
 == Ebuild Functions ==
-Ebuilds provide the ability to define various shell functions that are used to specify various actions relating to building and installing a source or binary package on a user's system. These functions are defined below:
+Ebuilds provide the ability to define various shell functions that are used to specify various actions relating to building and installing a source or binary package on a user's system. When an ebuild is emerged, the following functions are called, in order:
 === src_* functions ===

← Older revision		Revision as of 15:54, 12 January 2012
Line 86:		Line 86:

	The <tt>pkg_postrm</tt> function is called by Portage after an ebuild is removed from the filesystem.		The <tt>pkg_postrm</tt> function is called by Portage after an ebuild is removed from the filesystem.
		+
		+	==== pkg_config ====
		+
		+	The <tt>pkg_config</tt> function is called by Portage when the user calls <tt>emerge --config</tt> for the ebuild. The current directory will be set to the current directory of the shell from where <tt>emerge --config</tt> is run.

	=== Extra pre_ and post_ functions ===		=== Extra pre_ and post_ functions ===

@@ Line 55: / Line 55: @@
 <pre>
 src_install() {
-   make DESTIDR="$D" install
+   make DESTDIR="$D" install
+}
 </pre>

@@ Line 89: / Line 89: @@
 === Extra pre_ and post_ functions ===
-Modern versions of Portage also support functions identical to the above functions but with '''pre_''' and '''post_''' at the beginning of the function name. For example, <tt>post_src_configure</tt> will be executed after <tt>src_configure</tt> and before <tt>src_compile</tt>. These additional functions are supported by all EAPIs, provided that the parent function is supported by the EAPI in use. The initial current working directory should be identical to the initial current working directory of the parent function. '''You should avoid using it into ebuilds because there is no reason to do so, it may become handy with custom bashrc's functions'''.
+Modern versions of Portage also support functions identical to the above functions but with '''pre_''' and '''post_''' at the beginning of the function name. For example, <tt>post_src_configure</tt> will be executed after <tt>src_configure</tt> and before <tt>src_compile</tt>. These additional functions are supported by all EAPIs, provided that the parent function is supported by the EAPI in use. The initial current working directory should be identical to the initial current working directory of the parent function.
 === Helper Functions ===

@@ Line 89: / Line 89: @@
 === Extra pre_ and post_ functions ===
-Modern versions of Portage also support functions identical to the above functions but with '''pre_''' and '''post_''' at the beginning of the function name. For example, <tt>post_src_configure</tt> will be executed after <tt>src_configure</tt> and before <tt>src_compile</tt>. These additional functions are supported by all EAPIs, provided that the parent function is supported by the EAPI in use. The initial current working directory should be identical to the initial current working directory of the parent function.
+Modern versions of Portage also support functions identical to the above functions but with '''pre_''' and '''post_''' at the beginning of the function name. For example, <tt>post_src_configure</tt> will be executed after <tt>src_configure</tt> and before <tt>src_compile</tt>. These additional functions are supported by all EAPIs, provided that the parent function is supported by the EAPI in use. The initial current working directory should be identical to the initial current working directory of the parent function. '''You should avoid using it into ebuilds because there is no reason to do so, it may become handy with custom bashrc's functions'''.
 === Helper Functions ===

← Older revision		Revision as of 01:24, 18 January 2011
Line 129:		Line 129:

	[[Category:Internals]]		[[Category:Internals]]
		+	[[Category:Portage]]

@@ Line 95: / Line 95: @@
 ==== econf() ====
-econf() is part of ebuild.sh and was originally intended to be a wrapper to the <tt>configure</tt> command that is typically used in the <tt>src_configure</tt> stage. It has a number of behaviors that are important for ebuild writers to understand.
+econf() is part of ebuild.sh and is intended to be a wrapper to the <tt>configure</tt> command that is typically used in the <tt>src_configure()</tt> stage. It has a number of behaviors that are important for ebuild writers to understand. Once you understand what <tt>econf()</tt> does, you are free to use it in your ebuilds. Note that the behavior of <tt>econf()</tt> is generally safe for most autoconf-based source archives, but in some cases it may be necessary to avoid using <tt>econf()</tt> to avoid some of its default behaviors.
 ===== Automatically set prefix =====
-<tt>--prefix=$EPREFIX/usr</tt> will be passed to <tt>configure</tt> automatically, unless a <tt>--prefix</tt> argument was specified to <tt>econf</tt>, in which case, that <tt>--prefix</tt> setting will be used instead.
+<tt>--prefix=/usr</tt> will be passed to <tt>configure</tt> automatically, unless a <tt>--prefix</tt> argument was specified to <tt>econf()</tt>, in which case, that <tt>--prefix</tt> setting will be used instead.
 ===== Automatically set libdir =====
-If the <tt>ABI</tt> variable is set (typically done in the profile), then <tt>econf</tt> will look for a variable named <tt>LIBDIR_$ABI</tt> (ie. <tt>LIBDIR_amd64</tt>). If this variable is set, the value of this variable will be used to set <tt>libdir</tt> to the value of <tt>{prefix}/LIBDIR_$ABI</tt>.
+If the <tt>ABI</tt> variable is set (typically done in the profile), then <tt>econf()</tt> will look for a variable named <tt>LIBDIR_$ABI</tt> (ie. <tt>LIBDIR_amd64</tt>). If this variable is set, the value of this variable will be used to set <tt>libdir</tt> to the value of <tt>{prefix}/LIBDIR_$ABI</tt>.
 [[Category:Internals]]

← Older revision		Revision as of 05:27, 23 December 2010
Line 95:		Line 95:
	;econf()		;econf()
	: econf() is part of ebuild.sh and was originally intended to be a wrapper to the <tt>configure</tt> command that is typically used in the <tt>src_configure</tt> stage. Currently, econf() is ~84 lines and its behavior changes depending upon which EAPI you happen to be using. For this reason, the use of econf() is strongly discouraged at this time, and the Funtoo Linux core team recommends that you call ./configure directly.		: econf() is part of ebuild.sh and was originally intended to be a wrapper to the <tt>configure</tt> command that is typically used in the <tt>src_configure</tt> stage. Currently, econf() is ~84 lines and its behavior changes depending upon which EAPI you happen to be using. For this reason, the use of econf() is strongly discouraged at this time, and the Funtoo Linux core team recommends that you call ./configure directly.
		+
		+	[[Category:Internals]]