not to be a killjoy but what about having all sub projects output to a common "build" directory then the filesets for assemblies and doc are as simple as:
<fileset id="ass-dll-fs">
<includes name="*.dll />
<fileset/>
and
<fileset id="ass-doc-fs">
<includes name="*.xml" />
<fileset/>
looking at your assumptions I've just realized that the list of datatype references isn't getting passed to nant calls - I'll go fix that.
The other concern is that if fileset references are mutable and a leaf node in a nant call tree can modify the global instance I forsee some tricky debugging situations where certain paths thru the dependency tree hit targets that modify global datatypes and cause unexpected behaviour in other leaf nodes . ie sub-project1 inlcudes master.build expecting to get a fileset as its defined, not realizing that this fileset it modified by sub-project2.
Ian
Hi Ian:
Here's a scenario:
1. You have a product that has a cascading set of sub-projects. 2. Some of these sub-projects are company wide class libraries used in more than one product line. 3. You have a product master.build file that will build the product. 4. Your master.build file calls into each sub-projects' build file to build the utilized class libraries. 5. Each sub-project conforms to a set of rules that says a. add your output assembly to fileset g-ass-dll-fs b. add your output xml doc to fileset g-ass-doc-fs 6. The product build file includes a generic company defined doc.build file that defines a sdk-doc target. 7. doc.build::sdk-doc target uses g-ass-dll-fs and g-ass-doc-fs to generate ndoc documentation.
Benefits: 1. encapsulation of build/output knowledge to the sub-projects. 2. decreased maintenance of master.build file due to benefit #1.
Assumptions: 1. filesets can be inherited by sub-projects. 2. filesets can be passed back up the call stack to master.build
Other supporting scenarios: 1. reference trees in <csc/> calls 2. release structure target copies
hth, -- Tom.
-----Original Message-----
From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 10:31 AM
Cc: [EMAIL PROTECTED]
Subject: Re: [nant-dev] Adding files to a fileset
Matthew Mastracci wrote:
I noticed some people talking earlier about having "build events" onfile, as it
the solution task. Perhaps it might be useful to add each
was compiled, to a named fileset and run a task (such as FxCop or obfuscation) on all the files after. What do you think?then use an
We could probably do it by writing each one to a file and
include that reads from a file as well, but adding the files to an existing fileset might be easier. :)hmm - it puts me in mind of the new feture in whitby where you 'll be able to re-open a c# class definition - multi-file classes. I'm worried that it could make readability a bit difficult. You could have to trace thru the execution path of the build file to see exacly which fileset you were using.
What about something like this?
<fileset id="foo" mode="append"> ... </fileset>
<fileset id="foo" mode="remove"> ... </fileset>
Ian
Matt.fileset using
Ian MacLean wrote:
how do you mean ? do you mean with code -inside a task or in the
build file itself ? Right now you could add to a named
detail thatcode - since all references to a given type id are using the same instance of the fileset. This is due to an implementation
we shouldmay change however.
Inside the build file is a different matter. I'm not sure
case whereallow redefinition of a named fileset - can you think of a
http://www.inetu.net/partner/index.phpthis would be useful ?
Ian
Is it possible to add files to a named fileset once it has been created, or do you need to recreate it?
Matt.
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting
Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting
_______________________________________________
10% Monthlynant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get
Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
