Just some quick note : I added a pck-config functionset locally that would
allow us to determine the prefix of a certain package (or the version,
....).
In the functions, I actually just use ExecTask ....
In order to achieve this, I had to extend ExternalProgramBase with
properties to set the textwriter to write standard output and errors too, so
we can read the output and return it as result of these functions ...
Still need to clean it up and add more control over the "verbosity" of tasks
to ensure nothing is written to the build log when executing a task in a
function ...
Gert
----- Original Message -----
From: "Ian MacLean" <[EMAIL PROTECTED]>
To: "Gert Driesen" <[EMAIL PROTECTED]>
Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 2004 9:34 AM
Subject: Re: [nant-dev] Mono 1.0 / Using NAnt project for framework
discovery
> Gert Driesen wrote:
>
> >I haven't yet had time to look into this myself, so can you tell us what
> >tweaking you had to do to get NAnt working on mono beta 1 ?
> >
> >
> >
> sure - Just needed to change the path for framework assemblies in
> NAnt.exe.config from /usr/local/lib to /usr/local/lib/mono/1.1. The exe
> files are still all in /usr/local/bin which come to think of it won't
> work for a true side by side install. I also had to remove the encoding
> document from the xml header as that was causing it to fail with an xml
> load error.
>
> There are also a bunch of 'remapping' warnings when running as the
> assemblies we ship in the /lib directory for mono were built against
> unsigned versions of the mono system assemblies. This doesn't prevent it
> from working though.
>
> >Should we add a pkg-config "task" to NAnt, and use this "task" in the
NAnt
> >configuration file ?
> >
> >
> >
> I was actually thinking along similar lines. Someone would need to
> implement a pkg-config-sharp library which shouldn't be too much effort.
> It would be better to have that reside in the mono codebase if those
> guys are amenable to that.
>
> Using 'task' functionality from the config file is an interesting idea.
> re-using the functionality already defined in tasks would be a good
> thing. There would have to be restrictions of course as you can do lots
> of things in a build file that probably aren't appropriate in the config
> file.
>
> calling it 'project' inside the config file looks a bit funny. Maybe we
> could give it a different name but still use project loading
> functionality to process it.
>
> Ian
>
> >We could actually allow a project to be defined as part of the framework
> >node, that would really be powerful.
> >
> ><framework
> > name="mono-1.0"
> > family="mono"
> > version="1.0"
> > description="GNOME projects port of the .NET Framework"
> > runtimeengine="mono"
> > sdkdirectory="${prefix}/bin"
> > frameworkdirectory="${prefix}/bin"
> > frameworkassemblydirectory="${prefix}/lib"
> > clrversion="1.1.4322"
> > >
> > <project>
> > <pkg-config package="mono" variable="prefix" property="prefix" />
> > </project>
> > ....
> ></framework>
> >
> >We could then use actual NAnt tasks, expressions, ... to determine
> >information about the framework instead of having to implement "hacks"
for
> >this purpose ... For all frameworks except Mono, this project would only
be
> >a collection of <property> and <readregistry> tasks (for this last task,
we
> >would need to have the NAnt.Win32Tasks assembly loaded, so we should add
a
> >tasks fileset to the platform node (which would be better than having to
> >repeat the same includes for every framework).
> >
> >The caveats I see right now are :
> >
> >- all that tasks and expressions that you use in the project should not
rely
> >on any framework-related information, as at that time there is no such
thing
> >as a target framework, or runtime framework defined
(Project.TargetFramework
> >and Project.RuntimeFramework would be null), as we're in the process of
> >actually determining these.
> >- we would not be able to access the filename of the build file (as the
> >project would be constructed using an XML document that would not be
backed
> >by a file)
> >
> >But ofcourse, I haven't given this a lot of thought, so there might be
more
> >issues ...
> >
> >The properties referenced in attributes of the framework node, would then
be
> >expanded using the properties set as part of the framework project ...
> >
> >I really don't think this would require a lot of effort... I'd be happy
to
> >look into this ...
> >
> >What do you think ?
> >
> >Gert
> >
> >----- Original Message -----
> >From: "Ian MacLean" <[EMAIL PROTECTED]>
> >To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
> >Cc: "Scott Hernandez" <[EMAIL PROTECTED]>; "Gert Driesen"
> ><[EMAIL PROTECTED]>
> >Sent: Tuesday, May 04, 2004 5:37 PM
> >Subject: Re: Mono GAC
> >
> >
> >
> >
> >>Looks like its all ok now. After a bit of config file tweaking nant
> >>builds ok on the mono beta1 preview released today. Looks like we'll
> >>probably need to find a way to use pkg-config to determine the mono base
> >>directory but that will still be better than hardcoding it as we are
now.
> >>
> >>Ian
> >>
> >>Jaroslaw Kowalski wrote:
> >>
> >>
> >>
> >>>See this:
> >>>
> >>>
> >>>
>
>>http://lists.ximian.com/archives/public/mono-devel-list/2004-May/005227.ht
m
> >>
> >>
> >l
> >
> >
>
>>>http://lists.ximian.com/archives/public/mono-list/2004-April/019844.html
> >>>
> >>>Jarek
> >>>
> >>>----- Original Message -----
> >>>From: "Scott Hernandez" <[EMAIL PROTECTED]>
> >>>To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
> >>>Cc: "Gert Driesen" <[EMAIL PROTECTED]>; "Ian MacLean"
> >>><[EMAIL PROTECTED]>
> >>>Sent: Saturday, May 01, 2004 8:10 PM
> >>>Subject: Re: Mono GAC
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>I'm off the mono lists, what is the deal?
> >>>>
> >>>>----- Original Message -----
> >>>>From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hi guys!
> >>>>>
> >>>>>What do you think about the recent mono GAC "feature"? Should we
fight
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>the
> >>>
> >>>
> >>>
> >>>
> >>>>>idea or invent a way do handle it?
> >>>>>
> >>>>>The hack to detect system libraries in references and pass them
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>unqualified
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>would be huge and ugly.
> >>>>>
> >>>>>Jarek
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>--
> >>Ian MacLean, Developer,
> >>ActiveState, a division of Sophos
> >>http://www.ActiveState.com
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >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
> >
> >
>
>
> --
> Ian MacLean, Developer,
> ActiveState, a division of Sophos
> http://www.ActiveState.com
>
>
>
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
