Hi,
Okay I think I have a better idea now. So the difference seems to be
that on windows (win32) the AssemblyFolders is used to resolve a folder,
while the .pc file while list all of the dependent files in the
installed package (rpm). I think the two are fundamentally similar, and
(again from what I gather) it seems like the .pc file could also be used
to imitate the AssemblyFolders behavior by just grabbing the prefix in a
.pc file. Does that sound about right?
I like Jarek's idea of using a <search-path />, probably because it
reminds me of a ant's <classpath/> task...just as an aside what would
you think about calling it <classpath />? This task could use a fileset
behind the scenes, and have the additional behavior that if a .pc file
is found (or if there were a property on the <include package="true" />)
it reads the package file and pops out either just the prefix, or
prefix/*.dll, or all referenced files in the .pc file (one of these
options not all, maybe the last seems the most logical). Someone
deploying on mono only would still have the ability to specify a .pc
file, but a multi-platform application could either specify two paths
(i.e. c:/program files/nunit or /usr/lib) instead of (or in addition to
I guess) the .pc file. Any non-existent files would just be ignored.
So...something like this:
<classpath id="MyClassPath">
<include name="NAnt" package="true"/>
<include name="c:/program files/NAnt"/>
<include name="/usr/lib"/>
</classpath>
Would check for references in all locations that can be resolved (i.e.
where FileInfo or the package task find files). How does that sound?
Clayton
PS: I will start another stream for the <output-path/> Jarek.
> There can be a task for it:
>
> <search-path for="assemblies" action="clear" />
> <search-path for="assemblies" action="append"
> path="${path.to.some.package}" /> <search-path
> for="assemblies" action="append"
> path="${path.to.some.other.package}" /> <search-path
> for="assemblies" action="append"
> path="${path.to.some.other.package2}" />
>
> When you reference an assembly:
>
> <references basedir="bbb">
> <includes name="aaa.dll" />
> </references>
>
> and it's not found in "bbb/aaa.dll" it would be checked in
> the following
> places:
>
> 1. WINDOWS\Microsoft.NET\vx.y.z\aaa.dll
> 2. ${path.to.some.package}\aaa.dll
> 3. ${path.to.some.other.package}\aaa.dll
> 4. ${path.to.some.other.package2}\aaa.dll
>
> Note the for="assemblies" parameter. It can be used to specify various
> paths:
>
> <search-path for="resources" path="..." />
> <search-path for="tasks" path="..." />
> <search-path for="resources" path="..." />
> <search-path for="includes" path="..." />
> <search-path for="libraries" path="..." />
> ....
>
> In general this would enchance all filesets.
> To (partially) support mono packages we could have:
>
> <search-path for="assemblies" action="append" package="packageName" />
>
> which would just append the path based on the location of the
> package. This would be taken from AssemblyFolders on Windows
> and pkg-config or mono packages on Linux.
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=click
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
