From: Clayton H. <cla...@sp...> - 2004-05-28 14:43:20
|
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=3D"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=3D"MyClassPath"> <include name=3D"NAnt" package=3D"true"/> <include name=3D"c:/program files/NAnt"/> <include name=3D"/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: >=20 > <search-path for=3D"assemblies" action=3D"clear" /> > <search-path for=3D"assemblies" action=3D"append"=20 > path=3D"${path.to.some.package}" /> <search-path=20 > for=3D"assemblies" action=3D"append"=20 > path=3D"${path.to.some.other.package}" /> <search-path=20 > for=3D"assemblies" action=3D"append"=20 > path=3D"${path.to.some.other.package2}" /> >=20 > When you reference an assembly: >=20 > <references basedir=3D"bbb"> > <includes name=3D"aaa.dll" /> > </references> >=20 > and it's not found in "bbb/aaa.dll" it would be checked in=20 > the following > places: >=20 > 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 >=20 > Note the for=3D"assemblies" parameter. It can be used to specify = various > paths: >=20 > <search-path for=3D"resources" path=3D"..." /> > <search-path for=3D"tasks" path=3D"..." /> > <search-path for=3D"resources" path=3D"..." /> > <search-path for=3D"includes" path=3D"..." /> > <search-path for=3D"libraries" path=3D"..." /> > .... >=20 > In general this would enchance all filesets. > To (partially) support mono packages we could have: >=20 > <search-path for=3D"assemblies" action=3D"append" = package=3D"packageName" /> >=20 > which would just append the path based on the location of the=20 > package. This would be taken from AssemblyFolders on Windows=20 > and pkg-config or mono packages on Linux. |