|
| 1 | +# Copyright 1999-2013 Gentoo Foundation |
| 2 | +# Distributed under the terms of the GNU General Public License v2 |
| 3 | +# $Header: $ |
| 4 | + |
| 5 | +# NOTE: The comments in this file are for instruction and documentation. |
| 6 | +# They're not meant to appear with your final, production ebuild. Please |
| 7 | +# remember to remove them before submitting or committing your ebuild. That |
| 8 | +# doesn't mean you can't add your own comments though. |
| 9 | + |
| 10 | +# The 'Header' on the third line should just be left alone. When your ebuild |
| 11 | +# will be committed to cvs, the details on that line will be automatically |
| 12 | +# generated to contain the correct data. |
| 13 | + |
| 14 | +# The EAPI variable tells the ebuild format in use. |
| 15 | +# Defaults to 0 if not specified. |
| 16 | +# It is suggested that you use the latest EAPI approved by the Council. |
| 17 | +# The PMS contains specifications for all EAPIs. Eclasses will test for this |
| 18 | +# variable if they need to use EAPI > 0 features. |
| 19 | +EAPI=5 |
| 20 | + |
| 21 | +# inherit lists eclasses to inherit functions from. Almost all ebuilds should |
| 22 | +# inherit eutils, as a large amount of important functionality has been |
| 23 | +# moved there. For example, the epatch call mentioned below wont work |
| 24 | +# without the following line: |
| 25 | +inherit eutils |
| 26 | +# A well-used example of an eclass function that needs eutils is epatch. If |
| 27 | +# your source needs patches applied, it's suggested to put your patch in the |
| 28 | +# 'files' directory and use: |
| 29 | +# |
| 30 | +# epatch "${FILESDIR}"/patch-name-here |
| 31 | +# |
| 32 | +# eclasses tend to list descriptions of how to use their functions properly. |
| 33 | +# take a look at /usr/portage/eclass/ for more examples. |
| 34 | + |
| 35 | +# Short one-line description of this package. |
| 36 | +DESCRIPTION="This is a sample skeleton ebuild file" |
| 37 | + |
| 38 | +# Homepage, not used by Portage directly but handy for developer reference |
| 39 | +HOMEPAGE="http://foo.example.org/" |
| 40 | + |
| 41 | +# Point to any required sources; these will be automatically downloaded by |
| 42 | +# Portage. |
| 43 | +SRC_URI="ftp://foo.example.org/${P}.tar.gz" |
| 44 | + |
| 45 | + |
| 46 | +# License of the package. This must match the name of file(s) in |
| 47 | +# /usr/portage/licenses/. For complex license combination see the developer |
| 48 | +# docs on gentoo.org for details. |
| 49 | +LICENSE="" |
| 50 | + |
| 51 | +# The SLOT variable is used to tell Portage if it's OK to keep multiple |
| 52 | +# versions of the same package installed at the same time. For example, |
| 53 | +# if we have a libfoo-1.2.2 and libfoo-1.3.2 (which is not compatible |
| 54 | +# with 1.2.2), it would be optimal to instruct Portage to not remove |
| 55 | +# libfoo-1.2.2 if we decide to upgrade to libfoo-1.3.2. To do this, |
| 56 | +# we specify SLOT="1.2" in libfoo-1.2.2 and SLOT="1.3" in libfoo-1.3.2. |
| 57 | +# emerge clean understands SLOTs, and will keep the most recent version |
| 58 | +# of each SLOT and remove everything else. |
| 59 | +# Note that normal applications should use SLOT="0" if possible, since |
| 60 | +# there should only be exactly one version installed at a time. |
| 61 | +# DO NOT USE SLOT=""! This tells Portage to disable SLOTs for this package. |
| 62 | +SLOT="0" |
| 63 | + |
| 64 | +# Using KEYWORDS, we can record masking information *inside* an ebuild |
| 65 | +# instead of relying on an external package.mask file. Right now, you should |
| 66 | +# set the KEYWORDS variable for every ebuild so that it contains the names of |
| 67 | +# all the architectures with which the ebuild works. All of the official |
| 68 | +# architectures can be found in the arch.list file which is in |
| 69 | +# /usr/portage/profiles/. Usually you should just set this to "~x86". The ~ |
| 70 | +# in front of the architecture indicates that the package is new and should be |
| 71 | +# considered unstable until testing proves its stability. So, if you've |
| 72 | +# confirmed that your ebuild works on x86 and ppc, you'd specify: |
| 73 | +# KEYWORDS="~x86 ~ppc" |
| 74 | +# Once packages go stable, the ~ prefix is removed. |
| 75 | +# For binary packages, use -* and then list the archs the bin package |
| 76 | +# exists for. If the package was for an x86 binary package, then |
| 77 | +# KEYWORDS would be set like this: KEYWORDS="-* x86" |
| 78 | +# DO NOT USE KEYWORDS="*". This is deprecated and only for backward |
| 79 | +# compatibility reasons. |
| 80 | +KEYWORDS="~x86" |
| 81 | + |
| 82 | +# Comprehensive list of any and all USE flags leveraged in the ebuild, |
| 83 | +# with the exception of any ARCH specific flags, i.e. "ppc", "sparc", |
| 84 | +# "x86" and "alpha". Not needed if the ebuild doesn't use any USE flags. |
| 85 | +IUSE="gnome X" |
| 86 | + |
| 87 | +# A space delimited list of portage features to restrict. man 5 ebuild |
| 88 | +# for details. Usually not needed. |
| 89 | +#RESTRICT="strip" |
| 90 | + |
| 91 | + |
| 92 | +# Build-time dependencies, such as |
| 93 | +# ssl? ( >=dev-libs/openssl-0.9.6b ) |
| 94 | +# >=dev-lang/perl-5.6.1-r1 |
| 95 | +# It is advisable to use the >= syntax show above, to reflect what you |
| 96 | +# had installed on your system when you tested the package. Then |
| 97 | +# other users hopefully won't be caught without the right version of |
| 98 | +# a dependency. |
| 99 | +#DEPEND="" |
| 100 | + |
| 101 | +# Run-time dependencies. Must be defined to whatever this depends on to run. |
| 102 | +# The below is valid if the same run-time depends are required to compile. |
| 103 | +RDEPEND="${DEPEND}" |
| 104 | + |
| 105 | +# Source directory; the dir where the sources can be found (automatically |
| 106 | +# unpacked) inside ${WORKDIR}. The default value for S is ${WORKDIR}/${P} |
| 107 | +# If you don't need to change it, leave the S= line out of the ebuild |
| 108 | +# to keep it tidy. |
| 109 | +#S=${WORKDIR}/${P} |
| 110 | + |
| 111 | + |
| 112 | +# The following src_configure function is implemented as default by portage, so |
| 113 | +# you only need to call it if you need a different behaviour. |
| 114 | +# This function is available only in EAPI 2 and later. |
| 115 | +#src_configure() { |
| 116 | + # Most open-source packages use GNU autoconf for configuration. |
| 117 | + # The default, quickest (and preferred) way of running configure is: |
| 118 | + #econf |
| 119 | + # |
| 120 | + # You could use something similar to the following lines to |
| 121 | + # configure your package before compilation. The "|| die" portion |
| 122 | + # at the end will stop the build process if the command fails. |
| 123 | + # You should use this at the end of critical commands in the build |
| 124 | + # process. (Hint: Most commands are critical, that is, the build |
| 125 | + # process should abort if they aren't successful.) |
| 126 | + #./configure \ |
| 127 | + # --host=${CHOST} \ |
| 128 | + # --prefix=/usr \ |
| 129 | + # --infodir=/usr/share/info \ |
| 130 | + # --mandir=/usr/share/man || die |
| 131 | + # Note the use of --infodir and --mandir, above. This is to make |
| 132 | + # this package FHS 2.2-compliant. For more information, see |
| 133 | + # http://www.pathname.com/fhs/ |
| 134 | +#} |
| 135 | + |
| 136 | +# The following src_compile function is implemented as default by portage, so |
| 137 | +# you only need to call it, if you need different behaviour. |
| 138 | +# For EAPI < 2 src_compile runs also commands currently present in |
| 139 | +# src_configure. Thus, if you're using an older EAPI, you need to copy them |
| 140 | +# to your src_compile and drop the src_configure function. |
| 141 | +#src_compile() { |
| 142 | + # emake (previously known as pmake) is a script that calls the |
| 143 | + # standard GNU make with parallel building options for speedier |
| 144 | + # builds (especially on SMP systems). Try emake first. It might |
| 145 | + # not work for some packages, because some makefiles have bugs |
| 146 | + # related to parallelism, in these cases, use emake -j1 to limit |
| 147 | + # make to a single process. The -j1 is a visual clue to others |
| 148 | + # that the makefiles have bugs that have been worked around. |
| 149 | + |
| 150 | + #emake || die |
| 151 | +#} |
| 152 | + |
| 153 | +# The following src_install function is implemented as default by portage, so |
| 154 | +# you only need to call it, if you need different behaviour. |
| 155 | +# For EAPI < 4 src_install is just returing true, so you need to always specify |
| 156 | +# this function in older EAPIs. |
| 157 | +#src_install() { |
| 158 | + # You must *personally verify* that this trick doesn't install |
| 159 | + # anything outside of DESTDIR; do this by reading and |
| 160 | + # understanding the install part of the Makefiles. |
| 161 | + # This is the preferred way to install. |
| 162 | + #emake DESTDIR="${D}" install || die |
| 163 | + |
| 164 | + # When you hit a failure with emake, do not just use make. It is |
| 165 | + # better to fix the Makefiles to allow proper parallelization. |
| 166 | + # If you fail with that, use "emake -j1", it's still better than make. |
| 167 | + |
| 168 | + # For Makefiles that don't make proper use of DESTDIR, setting |
| 169 | + # prefix is often an alternative. However if you do this, then |
| 170 | + # you also need to specify mandir and infodir, since they were |
| 171 | + # passed to ./configure as absolute paths (overriding the prefix |
| 172 | + # setting). |
| 173 | + #emake \ |
| 174 | + # prefix="${D}"/usr \ |
| 175 | + # mandir="${D}"/usr/share/man \ |
| 176 | + # infodir="${D}"/usr/share/info \ |
| 177 | + # libdir="${D}"/usr/$(get_libdir) \ |
| 178 | + # install || die |
| 179 | + # Again, verify the Makefiles! We don't want anything falling |
| 180 | + # outside of ${D}. |
| 181 | + |
| 182 | + # The portage shortcut to the above command is simply: |
| 183 | + # |
| 184 | + #einstall || die |
| 185 | +#} |
0 commit comments