path: root/article/gettext/bash-by-example-p3.xml.pot

msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2010-10-22 00:23+0600\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(guide:link):5
msgid "/doc/en/articles/bash-by-example-p3.xml"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):6
msgid "Bash by example, Part 3"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(author:title):8
msgid "Author"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(mail:link):9
msgid "drobbins@gentoo.org"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(mail):9
msgid "Daniel Robbins"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(abstract):12
msgid "In his final Bash by example article, Daniel Robbins takes a good look at the Gentoo Linux ebuild system, an excellent example of the power of bash. Step by step, he shows you how the ebuild system was implemented, and touches on many handy bash techniques and design strategies. By the end of the article, you'll have a good grasp of what's involved in producing a full-blown bash-based application, as well as a start at coding your own auto-build system."
msgstr ""

#. The original version of this article was published on IBM developerWorks,
#. and is property of Westtech Information Services. This document is an updated
#. version of the original article, and contains various improvements made by the
#. Gentoo Linux Documentation team
#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(version):26
msgid "1.3"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(date):27
msgid "2005-10-09"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):30
msgid "Exploring the ebuild system"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):32
msgid "Enter the ebuild system"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):35
msgid "I've really been looking forward to this third and final <e>Bash by example</e> article, because now that we've already covered bash programming fundamentals in <uri link=\"/doc/en/articles/bash-by-example-p1.xml\">Part 1</uri> and <uri link=\"/doc/en/articles/bash-by-example-p2.xml\">Part 2</uri>, we can focus on more advanced topics, like bash application development and program design. For this article, I will give you a good dose of practical, real-world bash development experience by presenting a project that I've spent many hours coding and refining: The Gentoo Linux ebuild system."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):46
msgid "I'm the chief architect of Gentoo Linux, a next-generation Linux OS currently in beta. One of my primary responsibilities is to make sure that all of the binary packages (similar to RPM packages) are created properly and work together. As you probably know, a standard Linux system is not composed of a single unified source tree (like BSD), but is actually made up of about 25+ core packages that work together. Some of the packages include:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(th):57
msgid "Package"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(th):58
msgid "Description"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(ti):61
msgid "linux"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(ti):62
msgid "The actual kernel"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(ti):65
msgid "util-linux"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(ti):66
msgid "A collection of miscellaneous Linux-related programs"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(ti):69
msgid "e2fsprogs"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(ti):70
msgid "A collection of ext2 filesystem-related utilities"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(ti):73
msgid "glibc"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(ti):74
msgid "The GNU C library"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):78
msgid "Each package is in its own tarball and is maintained by separate independent developers, or teams of developers. To create a distribution, each package has to be separately downloaded, compiled, and packaged. Every time a package must be fixed, upgraded, or improved, the compilation and packaging steps must be repeated (and this gets old really fast). To help eliminate the repetitive steps involved in creating and updating packages, I created the ebuild system, written almost entirely in bash. To enhance your bash knowledge, I'll show you how I implemented the unpack and compile portions of the ebuild system, step by step. As I explain each step, I'll also discuss why certain design decisions were made. By the end of this article, not only will you have an excellent grasp of larger-scale bash programming projects, but you'll also have implemented a good portion of a complete auto-build system."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):96
msgid "Why bash?"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):99
msgid "Bash is an essential component of the Gentoo Linux ebuild system. It was chosen as ebuild's primary language for a number of reasons. First, it has an uncomplicated and familiar syntax that is especially well suited for calling external programs. An auto-build system is \"glue code\" that automates the calling of external programs, and bash is very well suited to this type of application. Second, Bash's support for functions allowed the ebuild system to have modular, easy-to-understand code. Third, the ebuild system takes advantage of bash's support for environment variables, allowing package maintainers and developers to configure it easily, on-the-fly."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):114
msgid "Build process review"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):117
msgid "Before we look at the ebuild system, let's review what's involved in getting a package compiled and installed. For our example, we will look at the \"sed\" package, a standard GNU text stream editing utility that is part of all Linux distributions. First, download the source tarball (<path>sed-3.02.tar.gz</path>) (see <uri link=\"#resources\">Resources</uri>). We will store this archive in <path>/usr/src/distfiles</path>, a directory we will refer to using the environment variable <c>$DISTDIR</c>. <c>$DISTDIR</c> is the directory where all of our original source tarballs live; it's a big vault of source code."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):128
msgid "Our next step is to create a temporary directory called <path>work</path>, which houses the uncompressed sources. We'll refer to this directory later using the <c>$WORKDIR</c> environment variable. To do this, change to a directory where we have write permission and type the following:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):135 ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):148
msgid "Uncompressing sed into a temporary directory"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):135
#, no-wrap
msgid "\n$ <i>mkdir work</i>\n$ <i>cd work</i>\n$ <i>tar xzf /usr/src/distfiles/sed-3.02.tar.gz</i>\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):141
msgid "The tarball is then decompressed, creating a directory called <path>sed-3.02</path> that contains all of the sources. We'll refer to the <path>sed-3.02</path> directory later using the environment variable <c>$SRCDIR</c>. To compile the program, type the following:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):148
#, no-wrap
msgid "\n$ <i>cd sed-3.02</i>\n$ <i>./configure --prefix=/usr</i>\n<comment>(autoconf generates appropriate makefiles, this can take a while)</comment>\n\n$ <i>make</i>\n\n<comment>(the package is compiled from sources, also takes a bit of time)</comment>\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):158
msgid "We're going to skip the \"make install\" step, since we are just covering the unpack and compile steps in this article. If we wanted to write a bash script to perform all these steps for us, it could look something like this:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):164
msgid "Sample bash script to perform the unpack/compile process"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):164
#, no-wrap
msgid "\n#!/usr/bin/env bash\n\nif [ -d work ]\nthen\n<comment># remove old work directory if it exists</comment>\n      rm -rf work\nfi\nmkdir work\ncd work\ntar xzf /usr/src/distfiles/sed-3.02.tar.gz\ncd sed-3.02\n./configure --prefix=/usr\nmake\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):183
msgid "Generalizing the code"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):186
msgid "Although this autocompile script works, it's not very flexible. Basically, the bash script just contains the listing of all the commands that were typed at the command line. While this solution works, it would be nice to make a generic script that can be configured quickly to unpack and compile any package just by changing a few lines. That way, it's much less work for the package maintainer to add new packages to the distribution. Let's take a first stab at doing this by using lots of different environment variables, making our build script more generic:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):197
msgid "A new, more general script"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):197
#, no-wrap
msgid "\n#!/usr/bin/env bash\n\n<comment># P is the package name</comment>\n\nP=sed-3.02\n\n<comment># A is the archive name</comment>\n\nA=${P}.tar.gz\n\nexport ORIGDIR=`pwd`\nexport WORKDIR=${ORIGDIR}/work\nexport SRCDIR=${WORKDIR}/${P}\n\nif [ -z \"$DISTDIR\" ]\nthen\n<comment># set DISTDIR to /usr/src/distfiles if not already set</comment>\n        DISTDIR=/usr/src/distfiles\nfi\nexport DISTDIR\n\nif [ -d ${WORKDIR} ]\nthen    \n<comment># remove old work directory if it exists</comment>\n        rm -rf ${WORKDIR}\nfi\n\nmkdir ${WORKDIR}\ncd ${WORKDIR}\ntar xzf ${DISTDIR}/${A}\ncd ${SRCDIR}\n./configure --prefix=/usr\nmake\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):233
msgid "We've added a lot of environment variables to the code, but it still does basically the same thing. However, now, to compile any standard GNU autoconf-based source tarball, we can simply copy this file to a new file (with an appropriate name to reflect the name of the new package it compiles), and then change the values of <c>$A</c> and <c>$P</c> to new values. All other environment variables automatically adjust to the correct settings, and the script works as expected. While this is handy, there's a further improvement that can be made to the code. This particular code is much longer than the original \"transcript\" script that we created. Since one of the goals for any programming project should be the reduction of complexity for the user, it would be nice to dramatically shrink the code, or at least organize it better. We can do this by performing a neat trick -- we'll split the code into two separate files. Save this file as <path>sed-3.02.ebuild</path>:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):249
msgid "sed-3.02.ebuild"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):249
#, no-wrap
msgid "\n<comment>#the sed ebuild file -- very simple!</comment>\nP=sed-3.02\nA=${P}.tar.gz\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):255
msgid "Our first file is trivial, and contains only those environment variables that must be configured on a per-package basis. Here's the second file, which contains the brains of the operation. Save this one as \"ebuild\" and make it executable:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):262
msgid "The ebuild script"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):262
#, no-wrap
msgid "\n#!/usr/bin/env bash\n\n\nif [ $# -ne 1 ]\nthen\n        echo \"one argument expected.\"\n        exit 1\nfi\n\nif [ -e \"$1\" ]\nthen\n        source $1\nelse\n        echo \"ebuild file $1 not found.\"\n        exit 1\nfi\n\nexport ORIGDIR=`pwd`\nexport WORKDIR=${ORIGDIR}/work\nexport SRCDIR=${WORKDIR}/${P}\n\nif [ -z \"$DISTDIR\" ]\nthen\n        <comment># set DISTDIR to /usr/src/distfiles if not already set</comment>\n        DISTDIR=/usr/src/distfiles\nfi\nexport DISTDIR\n\nif [ -d ${WORKDIR} ]\nthen    \n        # remove old work directory if it exists \n        rm -rf ${WORKDIR}\nfi\n\nmkdir ${WORKDIR}\ncd ${WORKDIR}\ntar xzf ${DISTDIR}/${A}\ncd ${SRCDIR}\n./configure --prefix=/usr\nmake\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):305
msgid "Now that we've split our build system into two files, I bet you're wondering how it works. Basically, to compile sed, type:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):310
msgid "Testing the above ebuild"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):310
#, no-wrap
msgid "\n$ <i>./ebuild sed-3.02.ebuild</i>\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):314
msgid "When \"ebuild\" executes, it first tries to \"source\" variable <c>$1</c>. What does this mean? From my previous article, recall that <c>$1</c> is the first command line argument -- in this case, <path>sed-3.02.ebuild</path>. In bash, the \"source\" command reads in bash statements from a file, and executes them as if they appeared immediately in the file the \"source\" command is in. So, \"source ${1}\" causes the \"ebuild\" script to execute the commands in <path>sed-3.02.ebuild</path>, which cause <c>$P</c> and <c>$A</c> to be defined. This design change is really handy, because if we want to compile another program instead of sed, we can simply create a new <path>.ebuild</path> file and pass it as an argument to our \"ebuild\" script. That way, the <path>.ebuild</path> files end up being really simple, while the complicated brains of the ebuild system get stored in one place -- our \"ebuild\" script. This way, we can upgrade or enhance the ebuild system simply by editing the \"ebuild\" script, keeping the implementation details outside of the ebuild files. Here's a sample ebuild file for <c>gzip</c>:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):332
msgid "gzip-1.2.4a.ebuild"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):332
#, no-wrap
msgid "\n<comment>#another really simple ebuild script!</comment>\nP=gzip-1.2.4a\nA=${P}.tar.gz\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):341
msgid "Adding functionality"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):344
msgid "OK, we're making some progress. But, there is some additional functionality I'd like to add. I'd like the ebuild script to accept a second command-line argument, which will be <c>compile</c>, <c>unpack</c>, or <c>all</c>. This second command-line argument tells the ebuild script which particular step of the build process to perform. That way, I can tell ebuild to unpack the archive, but not compile it (just in case I need to inspect the source archive before compilation begins). To do this, I'll add a case statement that will test variable <c>$2</c>, and do different things based on its value. Here's what the code looks like now:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):356
msgid "ebuild, revision 2"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):356
#, no-wrap
msgid "\n#!/usr/bin/env bash\n\nif [ $# -ne 2 ]\nthen\n        echo \"Please specify two args - .ebuild file and unpack, compile or all\"\n        exit 1\nfi\n\n\nif [ -z \"$DISTDIR\" ]\nthen\n<comment> # set DISTDIR to /usr/src/distfiles if not already set</comment>\n        DISTDIR=/usr/src/distfiles\nfi\nexport DISTDIR\n\nebuild_unpack() {\n        <comment> #make sure we're in the right directory</comment>\n        cd ${ORIGDIR}\n        \n        if [ -d ${WORKDIR} ]\n        then    \n                rm -rf ${WORKDIR}\n        fi\n\n        mkdir ${WORKDIR}\n        cd ${WORKDIR}\n        if [ ! -e ${DISTDIR}/${A} ]\n        then\n            echo \"${DISTDIR}/${A} does not exist.  Please download first.\"\n            exit 1\n        fi    \n        tar xzf ${DISTDIR}/${A}\n        echo \"Unpacked ${DISTDIR}/${A}.\"\n        #source is now correctly unpacked\n}\n\n\nebuild_compile() {\n        \n        <comment> #make sure we're in the right directory</comment>\n        cd ${SRCDIR}\n        if [ ! -d \"${SRCDIR}\" ]\n        then\n                echo \"${SRCDIR} does not exist -- please unpack first.\"\n                exit 1\n        fi\n        ./configure --prefix=/usr\n        make     \n}\n\nexport ORIGDIR=`pwd`\nexport WORKDIR=${ORIGDIR}/work\n\nif [ -e \"$1\" ]\nthen\n        source $1\nelse\n        echo \"Ebuild file $1 not found.\"\n        exit 1\nfi\n\nexport SRCDIR=${WORKDIR}/${P}\n\ncase \"${2}\" in\n        unpack)\n                ebuild_unpack\n                ;;\n        compile)\n                ebuild_compile\n                ;;\n        all)\n                ebuild_unpack\n                ebuild_compile\n                ;;\n        *)\n                echo \"Please specify unpack, compile or all as the second arg\"\n                exit 1\n                ;;\nesac\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):439
msgid "We've made a lot of changes, so let's review them. First, we placed the compile and unpack steps in their own functions, and called <c>ebuild_compile()</c> and <c>ebuild_unpack()</c>, respectively. This is a good move, since the code is getting more complicated, and the new functions provide some modularity, which helps to keep things organized. On the first line in each function, I explicitly <c>cd</c> into the directory I want to be in because, as our code is becoming more modular rather than linear, it's more likely that we might slip up and execute a function in the wrong current working directory. The <c>cd</c> commands explicitly put us in the right place, and prevent us from making a mistake later -- an important step -- especially if you will be deleting files inside the functions."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):453
msgid "Also, I added a useful check to the beginning of the <c>ebuild_compile()</c> function. Now, it checks to make sure the <c>$SRCDIR</c> exists, and, if not, it prints an error message telling the user to unpack the archive first, and then exits. If you like, you can change this behavior so that if <c>$SRCDIR</c> doesn't exist, our ebuild script will unpack the source archive automatically. You can do this by replacing <c>ebuild_compile()</c> with the following code:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):462
msgid "A new spin on ebuild_compile()"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):462
#, no-wrap
msgid "\nebuild_compile() {\n        <comment>#make sure we're in the right directory</comment>\n        if [ ! -d \"${SRCDIR}\" ]\n        then\n                ebuild_unpack\n        fi\n        cd ${SRCDIR}\n        ./configure --prefix=/usr\n        make     \n}\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):475
msgid "One of the most obvious changes in our second version of the ebuild script is the new case statement at the end of the code. This case statement simply checks the second command-line argument, and performs the correct action, depending on its value. If we now type:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):482
msgid "Default action"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):482
#, no-wrap
msgid "\n$ <i>ebuild sed-3.02.ebuild</i>\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):486
msgid "We'll actually get an error message. ebuild now wants to be told what to do, as follows:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):491
msgid "Unpacking"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):491
#, no-wrap
msgid "\n$ <i>ebuild sed-3.02.ebuild unpack</i>\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):495 ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):503
msgid "or:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):499
msgid "Compiling"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):499
#, no-wrap
msgid "\n$ <i>ebuild sed-3.02.ebuild compile</i>\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):507
msgid "Unpacking and compiling"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):507
#, no-wrap
msgid "\n$ <i>ebuild sed-3.02.ebuild all</i>\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(impo):511
msgid "If you provide a second command-line argument, other than those listed above, you get an error message (the * clause), and the program exits."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):519
msgid "Modularizing the code"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):522
msgid "Now that the code is quite advanced and functional, you may be tempted to create several more ebuild scripts to unpack and compile your favorite programs. If you do, sooner or later you'll come across some sources that do not use autoconf (<c>./configure</c>) or possibly others that have non-standard compilation processes. We need to make some more changes to the ebuild system to accommodate these programs. But before we do, it is a good idea to think a bit about how to accomplish this."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):532
msgid "One of the great things about hard-coding <c>./configure --prefix=/usr; make</c> into our compile stage is that, most of the time, it works. But, we must also have the ebuild system accommodate sources that do not use autoconf or normal Makefiles. To solve this problem, I propose that our ebuild script should, by default, do the following:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(li):541
msgid "If there is a configure script in <c>${SRCDIR}</c>, execute it as follows: <c>./configure --prefix=/usr</c>. Otherwise, skip this step."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(li):545
msgid "Execute the following command: make"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):548
msgid "Since ebuild only runs configure if it actually exists, we can now automatically accommodate those programs that don't use autoconf and have standard makefiles. But what if a simple \"make\" doesn't do the trick for some sources? We need a way to override our reasonable defaults with some specific code to handle these situations. To do this, we'll transform our <c>ebuild_compile()</c> function into two functions. The first function, which can be looked at as a \"parent\" function, will still be called <c>ebuild_compile()</c>. However, we'll have a new function, called <c>user_compile()</c>, which contains only our reasonable default actions:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):560
msgid "ebuild_compile() split into two functions"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):560
#, no-wrap
msgid "\nuser_compile() {\n        <comment>#we're already in ${SRCDIR}</comment>\n        if [ -e configure ]\n        then\n                #run configure script if it exists\n                ./configure --prefix=/usr\n        fi\n        #run make\n        make\n}              \n\nebuild_compile() {\n        if [ ! -d \"${SRCDIR}\" ]\n        then\n                echo \"${SRCDIR} does not exist -- please unpack first.\"\n                exit 1\n        fi\n        <comment>#make sure we're in the right directory</comment>\n        cd ${SRCDIR}\n        user_compile\n}\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):584
msgid "It may not seem obvious why I'm doing this right now, but bear with me. While the code works almost identically to our previous version of ebuild, we can now do something that we couldn't do before -- we can override <c>user_compile()</c> in <path>sed-3.02.ebuild</path>. So, if the default <c>user_compile()</c> function doesn't meet our needs, we can define a new one in our <path>.ebuild</path> file that contains the commands required to compile the package. For example, here's an ebuild file for <c>e2fsprogs-1.18</c>, which requires a slightly different <c>./configure</c> line:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):595
msgid "e2fsprogs-1.18.ebuild"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):595
#, no-wrap
msgid "\n<comment>#this ebuild file overrides the default user_compile()</comment>\nP=e2fsprogs-1.18\nA=${P}.tar.gz\n \nuser_compile() {\n       ./configure --enable-elf-shlibs\n       make\n}\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):606
msgid "Now, <c>e2fsprogs</c> will be compiled exactly the way we want it to be. But, for most packages, we can omit any custom <c>user_compile()</c> function in the <path>.ebuild</path> file, and the default <c>user_compile()</c> function is used instead."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):613
msgid "How exactly does the ebuild script know which <c>user_compile()</c> function to use? This is actually quite simple. In the ebuild script, the default <c>user_compile()</c> function is defined before the <path>e2fsprogs-1.18.ebuild</path> file is sourced. If there is a <c>user_compile()</c> in <path>e2fsprogs-1.18.ebuild</path>, it overwrites the default version defined previously. If not, the default <c>user_compile()</c> function is used."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):623
msgid "This is great stuff; we've added a lot of flexibility without requiring any complex code if it's not needed. We won't cover it here, but you could also make similar modifications to <c>ebuild_unpack()</c> so that users can override the default unpacking process. This could come in handy if any patching has to be done, or if the files are contained in multiple archives. It is also a good idea to modify our unpacking code so that it recognizes bzip2-compressed tarballs by default."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):636
msgid "Configuration files"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):639
msgid "We've covered a lot of sneaky bash techniques so far, and now it's time to cover one more. Often, it's handy for a program to have a global configuration file that resides in <path>/etc</path>. Fortunately, this is easy to do using bash. Simply create the following file and save it as <path>/etc/ebuild.conf</path>:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):646
msgid "/ect/ebuild.conf"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):646
#, no-wrap
msgid "\n<comment># /etc/ebuild.conf: set system-wide ebuild options in this file</comment>\n\n<comment># MAKEOPTS are options passed to make</comment>\nMAKEOPTS=\"-j2\"\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):653
msgid "In this example, I've included just one configuration option, but you could include many more. One of the beautiful things about bash is that this file can be parsed by simply sourcing it. This is a design trick that works with most interpreted languages. After <path>/etc/ebuild.conf</path> is sourced, <c>$MAKEOPTS</c> is defined inside our ebuild script. We'll use it to allow the user to pass options to make. Normally, this option would be used to allow the user to tell ebuild to do a parallel make. This is explained below."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(note):663
msgid "<b>What is a parallel make?</b> To speed compilation on multiprocessor systems, make supports compiling a program in parallel. This means that instead of compiling just one source file at a time, make compiles a user-specified number of source files simultaneously (so those extra processors in a multiprocessor system are used). Parallel makes are enabled by passing the <c>-j #</c> option to make, as follows: <c>make -j4 MAKE=\"make -j4\"</c>. This code instructs make to compile four programs simultaneously. The <c>MAKE=\"make -j4\"</c> argument tells make to pass the <c>-j4</c> option to any child make processes it launches."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):675
msgid "Here's the final version of our ebuild program:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre:caption):679
msgid "ebuild, the final version"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(pre):679
#, no-wrap
msgid "\n#!/usr/bin/env bash\n\nif [ $# -ne 2 ]\nthen\n        echo \"Please specify ebuild file and unpack, compile or all\"\n        exit 1\nfi\n\nsource /etc/ebuild.conf\n\nif [ -z \"$DISTDIR\" ]\nthen\n        <comment># set DISTDIR to /usr/src/distfiles if not already set</comment>\n        DISTDIR=/usr/src/distfiles\nfi\nexport DISTDIR\n\nebuild_unpack() {\n        <comment>#make sure we're in the right directory</comment>\n        cd ${ORIGDIR}\n        \n        if [ -d ${WORKDIR} ]\n        then    \n                rm -rf ${WORKDIR}\n        fi\n\n        mkdir ${WORKDIR}\n        cd ${WORKDIR}\n        if [ ! -e ${DISTDIR}/${A} ]\n        then\n                echo \"${DISTDIR}/${A} does not exist.  Please download first.\"\n                exit 1\n        fi\n        tar xzf ${DISTDIR}/${A}\n        echo \"Unpacked ${DISTDIR}/${A}.\"\n        <comment>#source is now correctly unpacked</comment>\n}\n\nuser_compile() {\n        <comment>#we're already in ${SRCDIR}</comment>\n        if [ -e configure ]\n        then\n                <comment>#run configure script if it exists</comment>\n                ./configure --prefix=/usr\n        fi\n        <comment>#run make</comment>\n        make $MAKEOPTS MAKE=\"make $MAKEOPTS\"  \n} \n\nebuild_compile() {\n        if [ ! -d \"${SRCDIR}\" ]\n        then\n                echo \"${SRCDIR} does not exist -- please unpack first.\"\n                exit 1\n        fi\n        <comment>#make sure we're in the right directory</comment>\n        cd ${SRCDIR}\n        user_compile\n}\n\nexport ORIGDIR=`pwd`\nexport WORKDIR=${ORIGDIR}/work\n\nif [ -e \"$1\" ]\nthen\n        source $1\nelse\n        echo \"Ebuild file $1 not found.\"\n        exit 1\nfi\n\nexport SRCDIR=${WORKDIR}/${P}\n\ncase \"${2}\" in\n        unpack)\n                ebuild_unpack\n                ;;\n        compile)\n                ebuild_compile\n                ;;\n        all)\n                ebuild_unpack\n                ebuild_compile\n                ;;\n        *)\n                echo \"Please specify unpack, compile or all as the second arg\"\n                exit 1\n                ;;\nesac\n"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):771
msgid "Notice <path>/etc/ebuild.conf</path> is sourced near the beginning of the file. Also, notice that we use <c>$MAKEOPTS</c> in our default <c>user_compile()</c> function. You may be wondering how this will work -- after all, we refer to <c>$MAKEOPTS</c> before we source <path>/etc/ebuild.conf</path>, which actually defines <c>$MAKEOPTS</c> in the first place. Fortunately for us, this is OK because variable expansion only happens when <c>user_compile()</c> is executed. By the time <c>user_compile()</c> is executed, <path>/etc/ebuild.conf</path> has already been sourced, and <c>$MAKEOPTS</c> is set to the correct value."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):785
msgid "Wrapping it up"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):788
msgid "We've covered a lot of bash programming techniques in this article, but we've only touched the surface of the power of bash. For example, the production Gentoo Linux ebuild system not only automatically unpacks and compiles each package, but it can also:"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(li):796
msgid "Automatically download the sources if they are not found in <c>$DISTDIR</c>"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(li):799
msgid "Verify that the sources are not corrupted by using MD5 message digests"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(li):802
msgid "If requested, install the compiled application into the live filesystem, recording all installed files so that the package can be easily uninstalled at a later date."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(li):807
msgid "If requested, package the compiled application in a tarball (compressed the way you like it) so that it can be installed later, on another computer, or during the CD-based installation process (if you are building a distribution CD)"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):815
msgid "In addition, the production ebuild system has several other global configuration options, allowing the user to specify options such as what optimization flags to use during compilation, and whether optional support for packages like GNOME and slang should be enabled by default in those packages that support it."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(p):822
msgid "It's clear that bash can accomplish much more than what I've touched on in this series of articles. I hope you've learned a lot about this incredible tool, and are excited about using bash to speed up and enhance your development projects."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):833
msgid "Resources"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(title):835
msgid "Useful links"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(li):839
msgid "Download the source tarball (<path>sed-3.02.tar.gz</path>) from <uri>ftp://ftp.gnu.org/pub/gnu/sed</uri>"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(li):843
msgid "Read <uri link=\"/doc/en/articles/bash-by-example-p1.xml\">Bash by example: Part 1</uri>."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(li):847
msgid "Read <uri link=\"/doc/en/articles/bash-by-example-p2.xml\">Bash by example: Part 2</uri>."
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(li):851
msgid "Visit the home page of the <uri link=\"http://gentoo.org\">Gentoo Project</uri>"
msgstr ""

#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(li):855
msgid "Check out the <uri link=\"http://www.gnu.org/software/bash/manual/bash.html\">bash online reference manual</uri>."
msgstr ""

#. Place here names of translator, one per line. Format should be NAME; ROLE; E-MAIL
#: ../../gentoo/xml/htdocs/doc/en/articles/bash-by-example-p3.xml(None):0
msgid "translator-credits"
msgstr ""