Re: [nant-dev] Mono 1.0 / Using NAnt project for framework discovery

Ian MacLean Thu, 06 May 2004 09:14:02 -0700

Gert Driesen wrote:

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)

looks pretty good. Does get-libs return the assemblies that make a package - so gtk-sparp, gdk-sharp etc for the gtk-sharp 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 ?

I'd need to have more knowledge of exactly what pkg-config does before making that call. I'm a little uneasy having a function set wrap an exe. Every call will result in the pkg-config binary being launched which seems a tad expensive. If we can persuade the upstream developers to provide a libpkg-config or somthing along those lines that would be nicer. Of course in the meantime the current impl should be ok.

Should we have a NAnt.UnixTasks assembly for this ?

Sure and for other things like chmod and chown tasks. Those will be pretty easy to add thanks ot the mono.Posix assembly

Ian

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

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

Re: [nant-dev] Mono 1.0 / Using NAnt project for framework discovery

Reply via email to