💎一站式轻松地调用各大LLM模型接口,支持GPT4、智谱、星火、月之暗面及文生图 广告
# 4.3 More Complex Buildfile ``` <?xml version="1.0" encoding="UTF-8" ?> <project name="testsite" basedir="." default="main"> <property file="./build.properties" /> <property name="package" value="${phing.project.name}" override="true" /> <property name="builddir" value="./build/testsite" override="true" /> <property name="srcdir" value="${project.basedir}" override="true" /> <!-- Fileset for all files --> <fileset dir="." id="allfiles"> <include name="**" /> </fileset> <!-- ============================================ --> <!-- (DEFAULT) Target: main --> <!-- ============================================ --> <target name="main" description="main target"> <copy todir="${builddir}"> <fileset refid="allfiles" /> </copy> </target> <!-- ============================================ --> <!-- Target: Rebuild --> <!-- ============================================ --> <target name="rebuild" description="rebuilds this package"> <delete dir="${builddir}" /> <phingcall target="main" /> </target> </project> ``` This build file first defines some properties with the `<property>` task call to `PropertyTask`. Then, it defines a [fileset](apds04.html "D.4 FileSet") and two [targets](aphs02.html "H.2 Targets"). Let us have a quick rundown of this build file. The first four tags within the `project` tag define properties. They appear in two possible variants: - The first `property` tag contains only the `file` attribute. The value has to be a relative or absolute path to a property file (for the format, see [Appendix聽J](apj.html "Appendix J. File Formats")). - The other times, the tag has a `name` and a `value` attribute. After the call, the value defined in the attribute `value` is available through the key enclosed in "${" and "}". The next noticeable thing in the build file is the `<fileset>` tag. It defines a `fileset`, i.e. a set of multiple files. You can include and exclude files with the `include` and `exclude` tags within the `fileset` tag. For more information concerning Filesets (i.e. Patterns) see [Appendix聽D](apd.html "Appendix D. Core Types"). The `fileset` is given an `id` attribute, so it can be referenced later on. One thing is worth noting here though and that is the use of double star expression, i.e. `"**"`. This special regexp refers to all files in all subdirectories as well. Compare this with a single `"*"` which would only refer to all files in the `current` subdirectory. So for example the expression `"**/*.phps"` would refer to all files with suffix `"'.phps"` in all subdirectories below the current directory. The first task only contains a call to `CopyTask` via `<copy>`. The interesting thing is within the `copy` tag. Here, a fileset task is not written out with nested `include` or `exclude` elements, but via the `refid`, the Fileset created earlier is referenced. This way, you can use a once defined fileset multiple times in your build files. The only noticeable thing in the second target is the call to `PhingTask` with the `<phingcall>` tag (see [Appendix聽B](apb.html "Appendix B. Core tasks") for more information). The task executes a specified target within the same build file. So, the second target removes the build directory and calls `main` again, thus rebuilding the project. A variant is to override properties defined in the build file with properties specified on the command line using the `-D` switch. For example to override the `builddir` in the build file above one could call Phing as `$ phing -Dbuilddir=/tmp/system-test `## @#@#@#@#@idp22 4.3.1 Handling source dependencies A common task required in many build files is to keep some target which has a number of dependencies up to date. In traditional make files this could for example be an executable that needs to be recompiled if any of the source files have been updated. In Phing such a condition is handled by the `UpToDateTask` , see [Section聽B.50](apbs50.html "B.50 UpToDateTask") for examples on how this task us used.