> ----- Original Message -----
> From: "Clayton Harbour" <[EMAIL PROTECTED]>
> To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>; "Gert Driesen"
<[EMAIL PROTECTED]>; "Nant-Developers (E-Mail)"
<[EMAIL PROTECTED]>
> Sent: Friday, May 28, 2004 4:43 PM
> Subject: RE: [nant-dev] Mono package references
>

> 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?

You're forgetting that AssemblyFolders are only used by the <solution> task.
None of the assembly references in the project files refer to package
names... I don't see how you can construct a list of (assembly) folders to
scan for assemblies without knowing what packages you should scan for
prefixes ?

> 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 />?

Ian recently added a <lib> element which can be used in combination with the
AssemblyFileSet to set the list of directories to scan for assembly
references.

eg.

<csc ...>
    <sources>
        ...
    </sources>
    <references>
        <include name="nunit.framework.dll" />
        <lib>
            <include name="C:\Program Files\ .... " />
            ....
        </lib>
    </references>
</csc>

> 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>

I can't see the advantage of this right now  ... I don't think its good to
always include a number of directory/packages that don't make sense on a
given platform/framework ...

I think users should be fully aware (and probably are) of the consequences
when they use package references ... But package references will not be a
Mono only features, as we will be able to resolve the package references
ourselves when targeting MS.NET (using pkg-config) and just pass these
command line options on to the MS compilers.

> Gert


-------------------------------------------------------
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_id=3149&alloc_id=8166&op=click
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to