summaryrefslogtreecommitdiff
path: root/eclass
diff options
context:
space:
mode:
authorDan Armak <danarmak@gentoo.org>2002-03-30 12:52:17 +0000
committerDan Armak <danarmak@gentoo.org>2002-03-30 12:52:17 +0000
commita196283e264623edd2f7c4c1618d32d53d5aa0e7 (patch)
treed8b91dfd6b19928c21190d01dfa21026845f5575 /eclass
parentVersion bump (diff)
downloadgentoo-2-a196283e264623edd2f7c4c1618d32d53d5aa0e7.tar.gz
gentoo-2-a196283e264623edd2f7c4c1618d32d53d5aa0e7.tar.bz2
gentoo-2-a196283e264623edd2f7c4c1618d32d53d5aa0e7.zip
make base_src_compile() use econf() and emake() from the default src_compile() in ebuild.sh
Diffstat (limited to 'eclass')
-rw-r--r--eclass/base.eclass6
-rw-r--r--eclass/doc/eclass-howto.lyx155
-rw-r--r--eclass/doc/eclass-howto.sgml94
3 files changed, 194 insertions, 61 deletions
diff --git a/eclass/base.eclass b/eclass/base.eclass
index f06cf8e6719b..edee50859900 100644
--- a/eclass/base.eclass
+++ b/eclass/base.eclass
@@ -1,7 +1,7 @@
# Copyright 1999-2000 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License, v2 or later
# Author Dan Armak <danarmak@gentoo.org>
-# $Header: /var/cvsroot/gentoo-x86/eclass/base.eclass,v 1.12 2002/03/27 22:33:53 danarmak Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/base.eclass,v 1.13 2002/03/30 12:52:14 danarmak Exp $
# The base eclass defines some default functions and variables. Nearly everything
# else inherits from here.
[ -n "$COMPAT" ] && inherit functions
@@ -52,11 +52,11 @@ base_src_compile() {
case $1 in
configure)
debug-print-section configure
- ./configure || die "died running ./configure, $FUNCNAME:configure"
+ econf || die "died running econf, $FUNCNAME:configure"
;;
make)
debug-print-section make
- make || die "died running make, $FUNCNAME:make"
+ emake || die "died running emake, $FUNCNAME:make"
;;
all)
debug-print-section all
diff --git a/eclass/doc/eclass-howto.lyx b/eclass/doc/eclass-howto.lyx
index c50275d5d721..5fbc6249d88d 100644
--- a/eclass/doc/eclass-howto.lyx
+++ b/eclass/doc/eclass-howto.lyx
@@ -30,63 +30,148 @@ eclass howto
Dan Armak
\layout Date
-Partailly updated for 20020206
+Updated for 20020330
\layout Section
-Warning
+Introduction
+\layout Subsection
+
+Overview
\layout Standard
-The eclasses have been modified and the documentation isn't up to date,
- to be fixed shortly.
-\layout Section
+eclasses are parts of ebuilds.
+ They are sourced (
+\begin_inset Quotes eld
+\end_inset
-Introduction
-\layout Standard
+inherited
+\begin_inset Quotes erd
+\end_inset
-eclasses are parts of ebuilds; that is, they have the same syntax ebuilds
- do, but do not define all the required variables and functions.
- ebuilds can inherit from eclasses, and eclasses can inherit from other
- eclasses.
+) by ebuilds and other eclasses, to provide default settings and functions
+ across many similar ebuilds.
As in OOP, this is used to ensure maximum code reuse among similar ebuilds.
\layout Standard
-This inheritance is implemented via simple bash sourcing.
- So, when you 'inherit
-\begin_inset Quotes erd
-\end_inset
+This first section shows briefly how to write an eclass.
+ The second is a detailed overview of all the existing eclasses.
+ The third explains how to write a KDE ebuild using the kde group of eclasses.
+\layout Subsection
- something its functions and variables override your own.
- For this reason, variables and functions are usually extended and not just
- set (more on this later).
+Example
\layout Standard
-The most uniform group of ebuilds is the kde apps.
- These were accordingly selected to be the test case for eclasses, and I
- believe I can now say the test has been successful.
- Eclasses for non-kde ebuilds may follow, but there are no concrete plans
- as of this time.
+Here is a fictive sourceforge.eclass, designed to provide homepage and download
+ locations to sourceforge.net-hosted projects:
+\layout Code
+
+# Copyright 2001-2002 Gentoo Technologies, Inc.
+\layout Code
+
+# Distributed under the terms of the GNU General Public License, v2 or later
+\layout Code
+
+# Author Dan Armak <danarmak@gentoo.org>
+\layout Code
+
+# $Header: /home/cvsroot/gentoo-x86/eclass/sourceforge.eclass,v 1.12 2002/03/27
+ 22:33:53 danarmak Exp $
+\layout Code
+
+\layout Code
+
+# This eclass sets $HOMEPAGE and $SRC_URI to the standard vaules for
+\layout Code
+
+# sourceforge.net - hosted projects.
+\layout Code
+
+\layout Code
+
+ECLASS=base
+\layout Code
+
+\layout Code
+
+HOMEPAGE="http://${PN}.sourceforge.net/"
+\layout Code
+
+SRC_URI="http://download.sourceforge.net/${PN}/${P}.tar.gz"
\layout Standard
-Because of the current customisable KDEDIR (KDE?DIR, KDE?LIBSDIR) scheme,
- all kde ebuilds (including ebuilds for apps with optional kde support)
-
-\emph on
-must
-\emph default
-use the eclasses.
- As a minimum, inherit kde-dirs to get the set-qtdir(), set-kdedir() functions.
+The first four lines are headers, just like those in any ebuild.
+ The next two lines are a short description of the eclass.
+ Line 7 sets $ECLASS to the eclass's name, which is useful for some applications
+ not seen in this example.
+ These are conventions you should follow.
+\layout Standard
+
+The rest of the code does the actual work - setting $SRC_URI and $HOMEPAGE.
+\layout Subsection
+
+There you go
+\layout Standard
+
+This is all you need to know to actually write eclasses.
+ Put your new eclass in /usr/portage/eclass/, and put these two lines at
+ the beginning of your ebuild:
+\layout Code
+
+.
+ /usr/portage/eclass/inherit.eclass || die
+\layout Code
+
+inherit sourceforge
+\layout Standard
+
+The first line is only needed for backward compatibility with <=portage-1.8.8,
+ i.e.
+ the rc6 profile.
+ The new 1.8.9 portage tree contains an inherit() function, but the old one
+ doesn't and so we have to manually source inherit.eclass which provides
+ it.
+ This backward support will be discontinued on April the 25th, one month
+ after the release of portage-1.8.9_pre32 for the 1.0 profile (the first portage
+ to include inherit() and some other eclass-supporting elements).
\layout Standard
-Section two explains how eclasses work; section three gives an example of
- a typical inheriting ebuild, and another of an ebuild for an app with optional
- kde functionality.
+Oh, and you can inherit several eclasses at the same time by saying:
+\layout Code
+
+inherit eclass1 eclass2 ...
+\layout Standard
+
+...but watch their order!
\layout Section
-The eclasses
+The current eclasses
\layout Standard
The best way of becoming familiar with the current eclass structure is an
explanation of what each eclass does.
+\layout Standard
+
+The most uniform group of ebuilds is the kde apps.
+ These were accordingly selected to be the test case for eclasses, and the
+ test has been successful.
+ Eclasses for non-kde ebuilds may follow, but there are no concrete plans
+ as of this time.
+ (Write a useful one!)
+\layout Standard
+
+Because of the current customisable KDEDIR (KDE?DIR, KDE?LIBSDIR) scheme,
+ all kde ebuilds (including ebuilds for apps with optional kde support)
+ need to
+\emph on
+
+\emph default
+use the eclasses, or else be forced to duplicate their functionality.
+ As a minimum, inherit kde-functions to get the set-qtdir(), set-kdedir()
+ functions.
+ See more in section 3.
+\layout Subsection
+
+ebuild.
\layout Subsection
inherit.eclass
diff --git a/eclass/doc/eclass-howto.sgml b/eclass/doc/eclass-howto.sgml
index 01f3c1f1fa3e..4ebc06cc8f8f 100644
--- a/eclass/doc/eclass-howto.sgml
+++ b/eclass/doc/eclass-howto.sgml
@@ -10,45 +10,93 @@
Dan Armak
</author>
<date>
- Updated for 20020206
+ Updated for 20020329
</date>
<sect1>
<title>
- Warning
+ Introduction
</title>
- <para>
- The eclasses have been modified and the documentation isn't up to date, to be fixed shortly.
- </para>
+ <sect2>
+ <title>
+ Overview
+ </title>
+ <para>
+ eclasses are parts of ebuilds. They are sourced (&ldquo;inherited&rdquo;) by ebuilds and other eclasses, to provide default settings and functions across many similar ebuilds. As in OOP, this is used to ensure maximum code reuse among similar ebuilds.
+ </para>
+ <para>
+ This first section shows briefly how to write an eclass. The second is a detailed overview of all the existing eclasses. The third explains how to write a KDE ebuild using the kde group of eclasses.
+ </para>
+ </sect2>
+ <sect2>
+ <title>
+ Example
+ </title>
+ <para>
+ Here is a fictive sourceforge.eclass, designed to provide homepage and download locations to sourceforge.net-hosted projects:
+ </para>
+ <programlisting>
+<![ CDATA [# Copyright 2001-2002 Gentoo Technologies, Inc.
+]]><![ CDATA [# Distributed under the terms of the GNU General Public License, v2 or later
+]]><![ CDATA [# Author Dan Armak <danarmak@gentoo.org>
+]]><![ CDATA [# $Header: /var/cvsroot/gentoo-x86/eclass/doc/eclass-howto.sgml,v 1.11 2002/03/30 12:52:17 danarmak Exp $
+]]><![ CDATA [
+]]><![ CDATA [# This eclass sets $HOMEPAGE and $SRC_URI to the standard vaules for
+]]><![ CDATA [# sourceforge.net - hosted projects.
+]]><![ CDATA [
+]]><![ CDATA [ECLASS=base
+]]><![ CDATA [
+]]><![ CDATA [HOMEPAGE="http://${PN}.sourceforge.net/"
+]]><![ CDATA [SRC_URI="http://download.sourceforge.net/${PN}/${P}.tar.gz"
+]]> </programlisting>
+ <para>
+ The first four lines are headers, just like those in any ebuild. The next two lines are a short description of the eclass. The seventh line set &dollar;ECLASS to the eclass's name, which is useful for some applications not seen in this example. The rest of the code does the actual work - setting SRC_URI and HOMEPAGE.
+ </para>
+ </sect2>
+ <sect2>
+ <title>
+ There you go
+ </title>
+ <para>
+ This is all you need to know to actually write eclasses. Put your new eclass in /usr/portage/eclass/, and put these two lines at the beginning of your ebuild:
+ </para>
+ <programlisting>
+<![ CDATA [. /usr/portage/eclass/inherit.eclass || die
+]]><![ CDATA [inherit sourceforge
+]]> </programlisting>
+ <para>
+ The first line is only needed for backward compatibility with &lt;=portage-1.8.8, i.e. the rc6 profile. The new 1.8.9 portage tree contains an inherit() function, but the old one doesn't and so we have to manually source inherit.eclass which provides it. This backward support will be discontinued on April the 25th, one month after the release of portage-1.8.9_pre32 for the 1.0 profile (the first portage to include inherit() and some other eclass-supporting elements).
+ </para>
+ <para>
+ Oh, and you can inherit several eclasses at the same time by saying:
+ </para>
+ <programlisting>
+<![ CDATA [inherit eclass1 eclass2 ...
+]]> </programlisting>
+ <para>
+ ...but watch their order!
+ </para>
+ </sect2>
</sect1>
<sect1>
<title>
- Introduction
+ The current eclasses
</title>
<para>
- eclasses are parts of ebuilds; that is, they have the same syntax ebuilds do, but do not define all the required variables and functions. ebuilds can inherit from eclasses, and eclasses can inherit from other eclasses. As in OOP, this is used to ensure maximum code reuse among similar ebuilds.
- </para>
- <para>
- This inheritance is implemented via simple bash sourcing. So, when you 'inherit&rdquo; something its functions and variables override your own. For this reason, variables and functions are usually extended and not just set (more on this later).
- </para>
- <para>
- The most uniform group of ebuilds is the kde apps. These were accordingly selected to be the test case for eclasses, and I believe I can now say the test has been successful. Eclasses for non-kde ebuilds may follow, but there are no concrete plans as of this time.
- </para>
- <para>
- Because of the current customisable KDEDIR (KDE?DIR, KDE?LIBSDIR) scheme, all kde ebuilds (including ebuilds for apps with optional kde support) <emphasis>must </emphasis>use the eclasses. As a minimum, inherit kde-dirs to get the set-qtdir(), set-kdedir() functions.
+ The best way of becoming familiar with the current eclass structure is an explanation of what each eclass does.
</para>
<para>
- Section two explains how eclasses work; section three gives an example of a typical inheriting ebuild, and another of an ebuild for an app with optional kde functionality.
+ The most uniform group of ebuilds is the kde apps. These were accordingly selected to be the test case for eclasses, and the test has been successful. Eclasses for non-kde ebuilds may follow, but there are no concrete plans as of this time. (Write a useful one!)
</para>
- </sect1>
- <sect1>
- <title>
- The eclasses
- </title>
<para>
- The best way of becoming familiar with the current eclass structure is an explanation of what each eclass does.
+ Because of the current customisable KDEDIR (KDE?DIR, KDE?LIBSDIR) scheme, all kde ebuilds (including ebuilds for apps with optional kde support) need to<emphasis> </emphasis>use the eclasses, or else be forced to duplicate their functionality. As a minimum, inherit kde-functions to get the set-qtdir(), set-kdedir() functions. See more in section 3.
</para>
<sect2>
<title>
+ ebuild.sh
+ </title>
+ </sect2>
+ <sect2>
+ <title>
inherit.eclass
</title>
<para>