Per concludere questo capitolo è doveroso esaminare una situazione più reale in cui i progetti da compilare sono più di uno. Nel caso in esame si hanno due progetti, uno per creare una libreria DLL, l'altro è la nostra oramai stranota applicazione Windows, che in questo caso dipende però dalla libreria.
Le particolarità da tenere in considerazione sono due:
- evitare di duplicare i task dello script
- gestire correttamente l'ordine di compilazione
Per risolvere questo tipico scenario utilizziamo il task <include>, nell'esempio 4 si nota la presenza di un file common.build, che raccoglie tutti i target standard per la build. Aprendolo si può notare come sia stato realizzato sulla base dello script dell'esempio precedente, in cui l'unica azione aggiunta è una compile-dll, per gestire la compilazione di progetti di tipo DLL, il resto dello script è quasi identico al precedente.
Il common.build è ora estremamente semplice:
<property name="path.root" value="." />
<include buildfile="${path.root}/Common.build" />
<fileset id="buildfiles.all">
<!-- I file devono essere in ordine di dipendenza -->
<include name="MyLibrary/Default.build" />
<include name="Winapp1/Default.build" />
</fileset>
<target name="buildall">
<nant target="build">
<buildfiles refid="buildfiles.all" />
</nant>
</target>
Dopo avere impostato il percorso path.root, che indica la directory radice dove operare, viene incluso con il task <include> il common.build, in questo modo è come se tutti i task di common.build fossero stati scritti in questo file.
Successivamente viene creata una lista di script da eseguire ed infine viene usato il task <nant>, che permette, con l'opzione <buildfiles>, di eseguire in cascata una sequenza di file di build. La modalità più diffusa di operare è infatti quella in cui ogni progetto ha il suo specifico file di build, ma grazie al common.build il contenuto di ognuno di essi è ridotto veramente all'osso.
Ecco ad esempio il contenuto dello script per compilare la MyLibrary.
<project name="MyLibrary"
default="build"
xmlns="http://nant.sf.net/nightly/2009-01-30-0.86/nant.xsd">
<property name="path.root" value=".." />
<include buildfile="${path.root}/Common.build" />
<property name="path.src" value="."/>
<property name="project.name" value="MyLibrary"/>
<fileset id="project.references" basedir="${path.build}" />
<target name="build" depends="compile-dll" />
</project>
In tutto è composto di sei task, i primi due servono ad includere il common.build, poi viene impostato il percorso dei file sorgenti (path.src) ed il project.name, poi viene specificata la lista delle references (project.references), che in questo caso è vuota, ed infine un target chiamato build, il cui unico scopo è dichiarare la dipendenza dalla compile-dll vista in precedenza.
Il file per l'applicativo windows è sostanzialmente identico.
<property name="path.root" value=".." />
<include buildfile="${path.root}/Common.build" />
<property name="path.src" value="."/>
<property name="project.name" value="MyTestApp1"/>
<fileset id="project.references" basedir="${path.build}">
<include name="MyLibrary.dll"/>
</fileset>
<echo message="${path.build}" />
<target name="build" depends="compile-winform" />
Il fattore importante è che nella definizione delle references, come directory base si è usata la variabile ${path.build}, in questo modo si è sicuri che tutte le references siano prese dal posto giusto, ovvero la cartella in cui lo script sta generando i progetti.
