"David Keber" <david_keber@...> wrote:
>I agree completely - but I wasn't sure how to implement that! Documentation
>is pretty sparse on it - but I will go spelunking through the code - do you
>have any pointers as to where to start?
You can have a look at src/NAnt.DotNet/Tasks/CompilerBase.cs I guess, but feel free to ask more specific questions ...
>That does get me wondering, the "imports" option is also a (comma) delimited
>list - but it is also implemented like my first suggestion for libpath - can
>we kill 2 birds with one stone and implement both of these options as
>filesets? This is a more controversial move - as it would break existing
We won't be able to replace the imports attribute with a fileset, as the imports option is a list of namespaces, not a list of file or directory names. We can however easily use an optionset or something similar, I was already thinking about adding something like that for the define attribute.
We should definitely not break existing scripts, but we can easily accomplish this by deprecating existing attributes and adding new functionality.
>I know for me personally, as a heavy uiser of the imports directive at the
>PROJECT level (not the individual source code file level), using the imports
>option as it is currently implemented in NAnt is a big pain - I just assumed
>that it was never implemented as a fileset because VB was the only language
>that actually allowed it! Is this the case? Or was there some other reason?
when we replace string attributes with a collection, we should make sure that we can reference the collection in tasks, like we currently allow for the fileset.
>Another reason to break these out into filesets - it would make it much
>easier to translate a .sln file to a .build script if this were the case!
>Where do we go from here?
Can you get started with fileset support for the libpath or do you need more information ?
Get latest updates about Open Source Projects, Conferences and News.