diff options
Diffstat (limited to 'eclass')
| -rw-r--r-- | eclass/doc/eclass-howto.lyx | 123 | ||||
| -rw-r--r-- | eclass/doc/eclass-howto.sgml | 215 | ||||
| -rw-r--r-- | eclass/doc/eclass-howto.txt | 92 |
3 files changed, 249 insertions, 181 deletions
diff --git a/eclass/doc/eclass-howto.lyx b/eclass/doc/eclass-howto.lyx index a00a041731eb..924d176a5c04 100644 --- a/eclass/doc/eclass-howto.lyx +++ b/eclass/doc/eclass-howto.lyx @@ -111,6 +111,9 @@ The second line would typically be: \layout Code inherit <list of eclasses> +\layout Subsubsection + +inherit() \layout Standard This eclass defines the inherit() function which handles sourcing of eclasses: @@ -140,14 +143,9 @@ inherit() { This function simply sources files from a hard-coded location. If, in the future, we will decide to move eclasses to a different location, any name-to-file resolution code will go in here. -\layout Subsection - -virtual.eclass -\layout Standard +\layout Subsubsection -This is sourced from inherit.eclass, and thus should always be present before - all other eclasses. - It defines EXPORT_FUNCTIONS(). +EXPORT_FUNCTIONS() \layout Standard Explanation: suppose A.eclass and B.eclass both define src_compile. @@ -224,21 +222,11 @@ The EXPORT_FUNCTIONS will call eval on the following string: \layout Code src_unpack() { foo_src_unpack() ; } -\layout Standard - -virtual.eclass defines all the ebuild functions (src_unpack, src_compile, - src_install, src_preinst, src_postinst, src_prerm, src_postrm) as empty - functions that do nothing (except call debug_print_function, see debug.eclass). \layout Subsection Function sections \layout Standard -Although this is not an integral part of eclasses, this is a good place - to introduce function sections. - -\layout Standard - One rarely uses predefined functions as-is; you usually want to extend them. Once they have unique names (foo_src_unpack) it's easy to add code that executes before or after them. @@ -428,10 +416,10 @@ debug.eclass \layout Standard Adds verbose output debugging functions. - Is inherited by virtual.eclass. + Is inherited by inherit.eclass. All eclasses call these functions a lot, which makes them look ugly but helps a great deal in tracing stuff, since there is no bash script debugger/ide -/step-by-step interpreter AFAIK (if you know of one, tell me!). +/step-by-step interpreter AFAIK (except for bash -x). \layout Standard Look at it to see the functions it provides, they are simplistic. @@ -556,23 +544,6 @@ cd ${S} \layout Code patch -p0 < ${FILESDIR}/${P}-gentoo.diff -\layout Standard - -There is also a helper function provided by base.eclass, called newdepend(). - It simply adds all parameters to both DEPEND and RDEPEND, saving you the - trouble of writing and maintaining two lists of dependencies. -\layout Subsection - -c.eclass -\layout Standard - -Adds gcc and glibc to DEPEND and RDEPEND. -\layout Subsection - -autoconf.eclass -\layout Standard - -Adds make/automake/autoconf to DEPEND. \layout Subsection autotools.eclass @@ -593,7 +564,7 @@ This eclass was made to bridge the incompatibility problem of autoconf-2.13, Read the eclass for more info. AFAIK it has no relationship whatsoever to an of the other eclasses. Contact Azarah for any further info. - (Azarah, you're welcome to feel in here). + (Azarah, you're welcome to fill in here). \layout Subsection kde.eclass @@ -631,7 +602,10 @@ Note: some kde apps, like widget styles and i18n packages, do not need to class. \layout Subsection -kde-dirs.eclass +functions.eclass +\layout Subsubsection + +kde-related (used to be kde-dirs.eclass) \layout Standard A short explanation about the current multi-kdedir scheme: @@ -691,13 +665,77 @@ In a ebuild with optional kde support, you inherit kde-dirs directly (and kde-dirs.eclass also contains several helper functions you shouldn't need to use directly. +\layout Subsubsection + +newdepend() +\layout Standard + +This function simply adds all parameters to both DEPEND and RDEPEND, saving + you the trouble of writing and maintaining two lists of dependencies. +\layout Standard + +If called with a special parameter, it adds predefined dependencies. + These special parmeters exst as of now: +\layout Description + + +\begin_inset Quotes eld +\end_inset + +/autotools +\begin_inset Quotes erd +\end_inset + +: add +\begin_inset Quotes eld +\end_inset + +sys-devel/autoconf sys-devel/automake sys-devel/make +\begin_inset Quotes erd +\end_inset + + to DEPEND (but not RDEPEND). +\layout Description + + +\begin_inset Quotes eld +\end_inset + +/c +\begin_inset Quotes erd +\end_inset + +: add +\begin_inset Quotes eld +\end_inset + +virtual/glibc sys-devel/ld.so +\begin_inset Quotes erd +\end_inset + + to both DEPEND and RDEPEND. + Also, add +\begin_inset Quotes eld +\end_inset + +sys-devel/gcc +\begin_inset Quotes erd +\end_inset + + to DEPEND. +\layout Standard + +This function encourages developers to maintain comprehensive DPEND strings. + Especially, many ebuilds have no RDEPEND strings, which will be a problem + once we have unmerge functionality that knows about dependencies. \layout Subsection kde-base.eclass \layout Standard Meant for standard kde apps; nearly all ebuilds use it. - Inherits c, kde. + Inherits kde. + Calls newdepend /c. Sets HOMEPAGE=apps.kde.com. \layout Subsection @@ -762,6 +800,10 @@ It provides a new src_unpack which sets SRC_URI= and copies the sources from a location hardcoded in the eclass. Useful if you have a local copy of the kde cvs modules. +\layout Standard + +It does not run cvs.cvsup itself beacuse that would violate the sanbox. + I plan to add a sanbox_allow command and implement that functionality. \layout Subsection kde-pre @@ -899,6 +941,9 @@ need-kde $version # minimal version of kde your app needs \layout Standard If you only need (optional) qt support, do the same, but call need-qt. + You can also disregard eclasses entirely, but make sure to add the correct + QT dep; the correct format as of now is e.g. + =x11-libs/qt-2* for qt2.x. \layout Standard Have fun! :-) - danarmak diff --git a/eclass/doc/eclass-howto.sgml b/eclass/doc/eclass-howto.sgml index 86a428ba6d1c..01f3c1f1fa3e 100644 --- a/eclass/doc/eclass-howto.sgml +++ b/eclass/doc/eclass-howto.sgml @@ -66,10 +66,14 @@ <programlisting> <![ CDATA [inherit <list of eclasses> ]]> </programlisting> - <para> - This eclass defines the inherit() function which handles sourcing of eclasses: - </para> - <programlisting> + <sect3> + <title> + inherit() + </title> + <para> + This eclass defines the inherit() function which handles sourcing of eclasses: + </para> + <programlisting> <![ CDATA [ECLASSDIR=/usr/portage/eclass ]]><![ CDATA [inherit() { ]]><![ CDATA [ while [ "$1" ]; do @@ -77,28 +81,25 @@ ]]><![ CDATA [ shift ]]><![ CDATA [ done ]]><![ CDATA [} -]]> </programlisting> - <para> - This function simply sources files from a hard-coded location. If, in the future, we will decide to move eclasses to a different location, any name-to-file resolution code will go in here. - </para> - </sect2> - <sect2> - <title> - virtual.eclass - </title> - <para> - This is sourced from inherit.eclass, and thus should always be present before all other eclasses. It defines EXPORT_FUNCTIONS(). - </para> - <para> - Explanation: suppose A.eclass and B.eclass both define src_compile. If you inherit both A and B you'll get a different src_compile depending on the order in which you inherit them. That's ok, you're supposed to keep track of your inheritance order. But you may want to call either of the two src_compile's explicitly. - </para> - <para> - So, every eclass adds to the functions that it defines a prefix. For example, A.eclass will define A_src_compile(), and B.eclass will define a B_src_compile(). That way, the ebuild can call either function and know what it'll get. - </para> - <para> - This raises a new problem: we need a function called src_compile so that the ebuild doesn't need to explicitly call something_src_compile. This is where EXPORT_FUNCTIONS() comes into play: - </para> - <programlisting> +]]> </programlisting> + <para> + This function simply sources files from a hard-coded location. If, in the future, we will decide to move eclasses to a different location, any name-to-file resolution code will go in here. + </para> + </sect3> + <sect3> + <title> + EXPORT_FUNCTIONS() + </title> + <para> + Explanation: suppose A.eclass and B.eclass both define src_compile. If you inherit both A and B you'll get a different src_compile depending on the order in which you inherit them. That's ok, you're supposed to keep track of your inheritance order. But you may want to call either of the two src_compile's explicitly. + </para> + <para> + So, every eclass adds to the functions that it defines a prefix. For example, A.eclass will define A_src_compile(), and B.eclass will define a B_src_compile(). That way, the ebuild can call either function and know what it'll get. + </para> + <para> + This raises a new problem: we need a function called src_compile so that the ebuild doesn't need to explicitly call something_src_compile. This is where EXPORT_FUNCTIONS() comes into play: + </para> + <programlisting> <![ CDATA [EXPORT_FUNCTIONS() { ]]><![ CDATA [ ]]><![ CDATA [ while [ "$1" ]; do @@ -107,32 +108,27 @@ ]]><![ CDATA [ done ]]><![ CDATA [ ]]><![ CDATA [} -]]> </programlisting> - <para> - Every eclass at its beginning sets $ECLASS to its name (e.g. “A” or “B”). Then it calls EXPORT_FUNCTIONS with the list of functions it provides. For example, if you call - </para> - <programlisting> +]]> </programlisting> + <para> + Every eclass at its beginning sets $ECLASS to its name (e.g. “A” or “B”). Then it calls EXPORT_FUNCTIONS with the list of functions it provides. For example, if you call + </para> + <programlisting> <![ CDATA [ECLASS=foo ]]><![ CDATA [EXPORT_FUNCTIONS src_unpack -]]> </programlisting> - <para> - The EXPORT_FUNCTIONS will call eval on the following string: - </para> - <programlisting> +]]> </programlisting> + <para> + The EXPORT_FUNCTIONS will call eval on the following string: + </para> + <programlisting> <![ CDATA [src_unpack() { foo_src_unpack() ; } -]]> </programlisting> - <para> - virtual.eclass defines all the ebuild functions (src_unpack, src_compile, src_install, src_preinst, src_postinst, src_prerm, src_postrm) as empty functions that do nothing (except call debug_print_function, see debug.eclass). - </para> +]]> </programlisting> + </sect3> </sect2> <sect2> <title> Function sections </title> <para> - Although this is not an integral part of eclasses, this is a good place to introduce function sections. - </para> - <para> One rarely uses predefined functions as-is; you usually want to extend them. Once they have unique names (foo_src_unpack) it's easy to add code that executes before or after them. Function sections break them down and allow code to execute between any two sections. </para> <para> @@ -206,7 +202,7 @@ debug.eclass </title> <para> - Adds verbose output debugging functions. Is inherited by virtual.eclass. All eclasses call these functions a lot, which makes them look ugly but helps a great deal in tracing stuff, since there is no bash script debugger/ide/step-by-step interpreter AFAIK (if you know of one, tell me!). + Adds verbose output debugging functions. Is inherited by inherit.eclass. All eclasses call these functions a lot, which makes them look ugly but helps a great deal in tracing stuff, since there is no bash script debugger/ide/step-by-step interpreter AFAIK (except for bash -x). </para> <para> Look at it to see the functions it provides, they are simplistic. @@ -262,25 +258,6 @@ <![ CDATA [cd ${S} ]]><![ CDATA [patch -p0 < ${FILESDIR}/${P}-gentoo.diff ]]> </programlisting> - <para> - There is also a helper function provided by base.eclass, called newdepend(). It simply adds all parameters to both DEPEND and RDEPEND, saving you the trouble of writing and maintaining two lists of dependencies. - </para> - </sect2> - <sect2> - <title> - c.eclass - </title> - <para> - Adds gcc and glibc to DEPEND and RDEPEND. - </para> - </sect2> - <sect2> - <title> - autoconf.eclass - </title> - <para> - Adds make/automake/autoconf to DEPEND. - </para> </sect2> <sect2> <title> @@ -293,7 +270,7 @@ This eclass was made to bridge the incompatibility problem of autoconf-2.13, autoconf-2.5x and automake-1.4x, automake-1.5x. Most packages needs autoconf-2.13 and automake-1.4x, but cannot work with the latest versions of these packages due to incompatibility, thus when we have a package that needs the latest versions of automake and autoconf, it begins to get a problem. </para> <para> - Read the eclass for more info. AFAIK it has no relationship whatsoever to an of the other eclasses. Contact Azarah for any further info. (Azarah, you're welcome to feel in here). + Read the eclass for more info. AFAIK it has no relationship whatsoever to an of the other eclasses. Contact Azarah for any further info. (Azarah, you're welcome to fill in here). </para> </sect2> <sect2> @@ -318,48 +295,83 @@ </sect2> <sect2> <title> - kde-dirs.eclass + functions.eclass </title> - <para> - A short explanation about the current multi-kdedir scheme: - </para> - <para> - $KDE{2,3}DIR and $KDELIBS{2,3}DIR are set in make.globals (and can be overridden in make.conf). Their default values are /usr/kde/{2,3}. - </para> - <para> - A package that identifies itself as a kde2 package (see below) will use the kdelibs installed in $KDELIBS2DIR and install itself into $KDE2DIR. Same goes for kde3. NOTE: separating kdelibs from kde apps and any other non-default KDEDIR stuff is untested and unsupported. - </para> - <para> - As for qt, the latest 2.x, 3.x version lives in /usr/qt/2,3 respectively. - </para> - <para> - The inner works of the system needn't be described here. A few weeks ago all this scheme was changed out of recognition, but no ebuilds needed to be changed, only eclasses. That speaks for their success. - </para> - <para> - This eclass provides two pairs of functions: need-kde(), need-qt() and set-kdedir(), set-qtdir(). These functions handle the details of the multi-qt and multi-kdelibs schemes. - </para> - <para> - The need-* functions are called with a parameter which is the version number required. They then add the corresponding dependencies to DEPEND and RDEPEND, and set the variables kde_version and qt_version which are used by the set-*dir functions. If no parameter is passed, a version number of 0 (zero) is used, meaning that any version will satisfy the dependency. - </para> - <para> - It is important to call these functions from the main part of the ebuild (i.e. not from a function), so that any changes to DEPEND and RDEPEND affect emerge. - </para> - <para> - The set-* dir functions are both called from the beginning of the configure section of the kde_src_compile() function. They set KDEDIR and QTDIR appropriately. That's all your ebuild should need. - </para> - <para> - In a ebuild with optional kde support, you inherit kde-dirs directly (and no other eclass). You should then call both need-* and set-* yourself. - </para> - <para> - kde-dirs.eclass also contains several helper functions you shouldn't need to use directly. - </para> + <sect3> + <title> + kde-related (used to be kde-dirs.eclass) + </title> + <para> + A short explanation about the current multi-kdedir scheme: + </para> + <para> + $KDE{2,3}DIR and $KDELIBS{2,3}DIR are set in make.globals (and can be overridden in make.conf). Their default values are /usr/kde/{2,3}. + </para> + <para> + A package that identifies itself as a kde2 package (see below) will use the kdelibs installed in $KDELIBS2DIR and install itself into $KDE2DIR. Same goes for kde3. NOTE: separating kdelibs from kde apps and any other non-default KDEDIR stuff is untested and unsupported. + </para> + <para> + As for qt, the latest 2.x, 3.x version lives in /usr/qt/2,3 respectively. + </para> + <para> + The inner works of the system needn't be described here. A few weeks ago all this scheme was changed out of recognition, but no ebuilds needed to be changed, only eclasses. That speaks for their success. + </para> + <para> + This eclass provides two pairs of functions: need-kde(), need-qt() and set-kdedir(), set-qtdir(). These functions handle the details of the multi-qt and multi-kdelibs schemes. + </para> + <para> + The need-* functions are called with a parameter which is the version number required. They then add the corresponding dependencies to DEPEND and RDEPEND, and set the variables kde_version and qt_version which are used by the set-*dir functions. If no parameter is passed, a version number of 0 (zero) is used, meaning that any version will satisfy the dependency. + </para> + <para> + It is important to call these functions from the main part of the ebuild (i.e. not from a function), so that any changes to DEPEND and RDEPEND affect emerge. + </para> + <para> + The set-* dir functions are both called from the beginning of the configure section of the kde_src_compile() function. They set KDEDIR and QTDIR appropriately. That's all your ebuild should need. + </para> + <para> + In a ebuild with optional kde support, you inherit kde-dirs directly (and no other eclass). You should then call both need-* and set-* yourself. + </para> + <para> + kde-dirs.eclass also contains several helper functions you shouldn't need to use directly. + </para> + </sect3> + <sect3> + <title> + newdepend() + </title> + <para> + This function simply adds all parameters to both DEPEND and RDEPEND, saving you the trouble of writing and maintaining two lists of dependencies. + </para> + <para> + If called with a special parameter, it adds predefined dependencies. These special parmeters exst as of now: + </para> + <variablelist> + <varlistentry> + <term> + “/autotools”: +</term><listitem><para>add “sys-devel/autoconf sys-devel/automake sys-devel/make” to DEPEND (but not RDEPEND). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + “/c”: +</term><listitem><para>add “virtual/glibc sys-devel/ld.so” to both DEPEND and RDEPEND. Also, add “sys-devel/gcc” to DEPEND. + </para> + </listitem> + </varlistentry> + </variablelist> + <para> + This function encourages developers to maintain comprehensive DPEND strings. Especially, many ebuilds have no RDEPEND strings, which will be a problem once we have unmerge functionality that knows about dependencies. + </para> + </sect3> </sect2> <sect2> <title> kde-base.eclass </title> <para> - Meant for standard kde apps; nearly all ebuilds use it. Inherits c, kde. Sets HOMEPAGE=apps.kde.com. + Meant for standard kde apps; nearly all ebuilds use it. Inherits kde. Calls newdepend /c. Sets HOMEPAGE=apps.kde.com. </para> </sect2> <sect2> @@ -405,6 +417,9 @@ <para> It provides a new src_unpack which sets SRC_URI=”” and copies the sources from a location hardcoded in the eclass. Useful if you have a local copy of the kde cvs modules. </para> + <para> + It does not run cvs.cvsup itself beacuse that would violate the sanbox. I plan to add a sanbox_allow command and implement that functionality. + </para> </sect2> <sect2> <title> @@ -468,7 +483,7 @@ ]]><![ CDATA [need-kde $version # minimal version of kde your app needs ]]> </programlisting> <para> - If you only need (optional) qt support, do the same, but call need-qt. + If you only need (optional) qt support, do the same, but call need-qt. You can also disregard eclasses entirely, but make sure to add the correct QT dep; the correct format as of now is e.g. =x11-libs/qt-2* for qt2.x. </para> <para> Have fun! :-) - danarmak diff --git a/eclass/doc/eclass-howto.txt b/eclass/doc/eclass-howto.txt index bb092ad54e8c..fc2baa4ad5d7 100644 --- a/eclass/doc/eclass-howto.txt +++ b/eclass/doc/eclass-howto.txt @@ -61,6 +61,8 @@ The second line would typically be: inherit <list of eclasses> +3.1.1 inherit() + This eclass defines the inherit() function which handles sourcing of eclasses: @@ -83,10 +85,7 @@ If, in the future, we will decide to move eclasses to a different location, any name-to-file resolution code will go in here. -3.2 virtual.eclass - -This is sourced from inherit.eclass, and thus should always -be present before all other eclasses. It defines EXPORT_FUNCTIONS(). +3.1.2 EXPORT_FUNCTIONS() Explanation: suppose A.eclass and B.eclass both define src_compile. If you inherit both A and B you'll get a different src_compile @@ -133,15 +132,7 @@ The EXPORT_FUNCTIONS will call eval on the following string: src_unpack() { foo_src_unpack() ; } -virtual.eclass defines all the ebuild functions (src_unpack, -src_compile, src_install, src_preinst, src_postinst, src_prerm, -src_postrm) as empty functions that do nothing (except call -debug_print_function, see debug.eclass). - -3.3 Function sections - -Although this is not an integral part of eclasses, this is -a good place to introduce function sections. +3.2 Function sections One rarely uses predefined functions as-is; you usually want to extend them. Once they have unique names (foo_src_unpack) @@ -246,13 +237,13 @@ when called with all or without parameters. Some sections may be non-standard and must be called explicitly. The only such section right now is base_src_compile patch. -3.4 debug.eclass +3.3 debug.eclass Adds verbose output debugging functions. Is inherited by -virtual.eclass. All eclasses call these functions a lot, +inherit.eclass. All eclasses call these functions a lot, which makes them look ugly but helps a great deal in tracing stuff, since there is no bash script debugger/ide/step-by-step -interpreter AFAIK (if you know of one, tell me!). +interpreter AFAIK (except for bash -x). Look at it to see the functions it provides, they are simplistic. @@ -309,7 +300,7 @@ there is no $RESULT in this sample function } -3.5 base.eclass +3.4 base.eclass This eclass defines some default variables and functions, similar to those you'd get by default in a non-inheriting @@ -326,20 +317,7 @@ cd ${S} patch -p0 < ${FILESDIR}/${P}-gentoo.diff -There is also a helper function provided by base.eclass, -called newdepend(). It simply adds all parameters to both -DEPEND and RDEPEND, saving you the trouble of writing and -maintaining two lists of dependencies. - -3.6 c.eclass - -Adds gcc and glibc to DEPEND and RDEPEND. - -3.7 autoconf.eclass - -Adds make/automake/autoconf to DEPEND. - -3.8 autotools.eclass +3.5 autotools.eclass This is made and maintained by Azarah. To quote his comments: @@ -353,9 +331,9 @@ to get a problem. Read the eclass for more info. AFAIK it has no relationship whatsoever to an of the other eclasses. Contact Azarah for -any further info. (Azarah, you're welcome to feel in here). +any further info. (Azarah, you're welcome to fill in here). -3.9 kde.eclass +3.6 kde.eclass Used by all kde apps, whether directly or indirectly. (Not by apps with optional kde functionality though.) This is @@ -381,7 +359,9 @@ not inherit c. These packages can then inherit straight from here. All other packages, which need to compile c code, should inherit from kde-base.eclass. -3.10 kde-dirs.eclass +3.7 functions.eclass + +3.7.1 kde-related (used to be kde-dirs.eclass) A short explanation about the current multi-kdedir scheme: @@ -431,12 +411,34 @@ need-* and set-* yourself. kde-dirs.eclass also contains several helper functions you shouldn't need to use directly. -3.11 kde-base.eclass +3.7.2 newdepend() + +This function simply adds all parameters to both DEPEND and +RDEPEND, saving you the trouble of writing and maintaining +two lists of dependencies. + +If called with a special parameter, it adds predefined dependencies. +These special parmeters exst as of now: + +"/autotools": add "sys-devel/autoconf + sys-devel/automake sys-devel/make" + to DEPEND (but not RDEPEND). + +"/c": add "virtual/glibc sys-devel/ld.so" + to both DEPEND and RDEPEND. Also, add "sys-devel/gcc" + to DEPEND. + +This function encourages developers to maintain comprehensive +DPEND strings. Especially, many ebuilds have no RDEPEND +strings, which will be a problem once we have unmerge functionality +that knows about dependencies. + +3.8 kde-base.eclass Meant for standard kde apps; nearly all ebuilds use it. Inherits -c, kde. Sets HOMEPAGE=apps.kde.com. +kde. Calls newdepend /c. Sets HOMEPAGE=apps.kde.com. -3.12 kde-i18n.eclass +3.9 kde-i18n.eclass Meant for the kde-i18n-* packages. Niche use. @@ -447,7 +449,7 @@ ${P} does the rest. Inherits kde, kde.org. Makes a few differences, such as PROVIDE virtual/kde-i18n, correct $S, HOMEPAGE and DESCRIPTION. -3.13 koffice-i18n.eclass +3.10 koffice-i18n.eclass Meant for the koffice-i18n-* packages. Niche use. Very similar to kde-i18n.eclass. @@ -455,7 +457,7 @@ to kde-i18n.eclass. All kde-i18n ebuilds are completely identical and so all they have to do is inherit from this eclass. -3.14 kde-dist.eclass +3.11 kde-dist.eclass Meant for the base kde distribution packages in kde-base/*. Inherits kde-base, kde.org. Adds the correct DESCRIPTION @@ -463,7 +465,7 @@ and HOMEPAGE and kdelibs-${PV} deps. The simpler/smaller kde-base/ packages (e.g. kdetoys) make no changes at all; most of those that do only add deps. -3.15 kde-cvs +3.12 kde-cvs This is only included with the kde3-pre ebuilds, and doesn't live in portage. See [http://www.gentoo.org/~danarmak/kde3-pre.html||http://www.gentoo.org/~danarmak/kde3-pre.html]. @@ -472,7 +474,11 @@ It provides a new src_unpack which sets SRC_URI="" and copies the sources from a location hardcoded in the eclass. Useful if you have a local copy of the kde cvs modules. -3.16 kde-pre +It does not run cvs.cvsup itself beacuse that would violate +the sanbox. I plan to add a sanbox_allow command and implement +that functionality. + +3.13 kde-pre This is only included with the kde3-pre ebuilds, and doesn't live in portage. See [http://www.gentoo.org/~danarmak/kde3-pre.html||http://www.gentoo.org/~danarmak/kde3-pre.html]. @@ -543,6 +549,8 @@ inherit kde-dirs need-kde $version # minimal version of kde your app needs If you only need (optional) qt support, do the same, but -call need-qt. +call need-qt. You can also disregard eclasses entirely, +but make sure to add the correct QT dep; the correct format +as of now is e.g. =x11-libs/qt-2* for qt2.x. Have fun! :-) - danarmak |