Ian,
we could have the following set of functions :
pkg-config::get-variable(string package, string variable)
pkg-config::exists(string package)
pkg-config::is-atleast-version(string package, string version)
pkg-config::is-max-version(string package, string version)
pkg-config::get-mod-version(string package)
pkg-config::get-libs(string package)
pkg-config::get-cflags(string package)
What do you think ? Is this how we should proceed, or will it be better to
have a task (or set of tasks) for this purpose ?
Should we have a NAnt.UnixTasks assembly for this ?
Gert
----- Original Message -----
From: "Gert Driesen" <[EMAIL PROTECTED]>
To: "Ian MacLean" <[EMAIL PROTECTED]>
Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 2004 10:04 PM
Subject: Re: [nant-dev] Mono 1.0 / Using NAnt project for framework
discovery
> 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
>
-------------------------------------------------------
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