There has been a lot of recent activity around the <solution> task. Most people seem
to be using this to ensure that their builds proceed in
the correct sequence. Just for interest, I'd like to share an idea I had when I first
started using NAnt. For large projects, it still seems
to be a better solution than <solution>.
In the compilation commands (e.g. <csc> for C#) one must list the references that the
code makes to other assemblies. It strikes me that if
NAnt were to allow one to embed a <nant> tag inside each tag indicating an individual
reference, then this would create an elegant system of
cascading builds. In essence, "here is an assembly that you will need in order to
build the target, and here is the build file to build that
assembly." Since .NET explicitly disallows circular references between assemblies,
this would produce a system in which NAnt could walk a
tree of build files, rebuilding the system in the correct sequence every time. It
would be scalable (the size of the system and the number
of dependencies would not matter).
The problem I see with the <solution> system is that it assumes that the organization
of source files into projects (<solution>s) when the
software was built is an organization that will permanent. In my experience, the way
that source files are built and deployed often ceases
to make any sense after the (business) project is over, so one is left with a bunch of
solution files that don't bear much resemblance to
the way that the software is logically organized.
The only problem I can see with this idea is that one would have to change the use of
the generic <includes> tag under <references> to
something more particular, such as <reference>. However, I still think it would be
worth the loss of a little orthogonality:
<csc target="${target.type}" output="${project.output}" debug="${debug}"
rootnamespace="${rootNamespace}" win32icon="App.ico">
<sources>
<includes name="AssemblyInfo.cs" />
...
<includes name="TextPrintDocument.cs" />
</sources>
<resources>
<includes name="WindowsCrystalReportViewer.resx" />
<includes name="WindowsPrintingPasswordDialog.resx" />
<includes name="WindowsPrintPreviewDialogExtended.resx" />
</resources>
<references>
<reference name="System.dll" />
<reference name="System.Data.dll" />
<reference name="System.Drawing.dll" />
<reference name="System.Windows.Forms.dll" />
<reference name="System.Xml.dll" />
<reference name="${dir.lib}/AgamaLibrary.dll">
<nant buildfile="../AgamaLibrary/AgamaLibrary.build" target="build"/>
</reference>
<reference name="${dir.lib}/CrystalDecisions.Shared.dll" />
<reference name="${dir.lib}/CrystalDecisions.ReportSource.dll" />
<reference name="${dir.lib}/CrystalDecisions.CrystalReports.Engine.dll" />
<reference name="${dir.lib}/CrystalDecisions.Windows.Forms.dll" />
<reference name="${dir.output}/Interop.Office.dll">
<call target="Office-build"/>
</reference>
<reference name="${dir.output}/Interop.Outlook.dll">
<call target="Outlook-build"/>
</reference>
</references>
</csc>
As you can see, one could use the same mechanism to call other targets within the same
build file in order to build interop assemblies and
things like that. Although this offers no functional advantage, it does organize the
build file more logically, in effect documenting why
the other targets exist.
Does anyone else think that this would be a worthy enhancement to NAnt?
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
