Clayton,
I'll have a look at this later (not sure if that will be today), but I think
this is related to the following issue I reported :
http://bugzilla.ximian.com/show_bug.cgi?id=57602
Gert
----- Original Message -----
From: "Clayton Harbour" <[EMAIL PROTECTED]>
To: "Ian MacLean" <[EMAIL PROTECTED]>
Cc: "Gert Driesen" <[EMAIL PROTECTED]>; "Nant-Developers (E-Mail)"
<[EMAIL PROTECTED]>
Sent: Thursday, May 06, 2004 4:17 AM
Subject: RE: [nant-dev] Mono 1.0 / Using NAnt project for framework
discovery
I have just deleted an assembly, and log4net from the build/bin root
directory, but this typically occurs on the first assembly that is compiled.
Here it is:
[nant]
/home/claytonharbour/dev/src/nant/nant/src/NAnt.DotNet/NAnt.DotNet.build
build
Buildfile:
file://home/claytonharbour/dev/src/nant/nant/src/NAnt.DotNet/NAnt.DotNet.build
Target(s) specified: build
build:
[csc] Compiling 18 files to
'/home/claytonharbour/dev/src/nant/nant/build/mono-1.0.unix/nant-0.85-debug/
bin/NAnt.DotNetTasks.dll'.
** (/usr/bin/mcs.exe:21160): WARNING **: Could not
find assembly log4net, references from
/home/claytonharbour/dev/src/nant/nant/build/mono-1.0.unix/nant-0.85-debug/b
in/NAnt.Core.dll (assemblyref_index=1)
Major/Minor: 1,2
Build: 0,30714
Token: (null)
Unhandled Exception: System.NullReferenceException:
A null value was found where an object instance was required.
in (unmanaged)
/usr/lib/libmono.so.0(mono_assembly_open+0x1b9) [0x49f797]
in (unmanaged) /usr/lib/libmono.so.0 [0x48f9ff]
in <0x000d1> Mono.CSharp.Driver:LoadAssembly
(string,bool)
in <0x0009f> Mono.CSharp.Driver:LoadReferences ()
in <0x006ac> Mono.CSharp.Driver:MainDriver
(string[])
in <0x0001a> Mono.CSharp.Driver:Main (string[])
BUILD FAILED
/home/claytonharbour/dev/src/nant/nant/src/NAnt.DotNet/NAnt.DotN
et.build(11,9):
External Program Failed: /usr/bin/mcs.exe (return code was 1)
Do you have the dlls somewhere in your path?
-----Original Message-----
From: Ian MacLean [mailto:[EMAIL PROTECTED]
Sent: Wed 5/5/2004 8:01 AM
To: Clayton Harbour
Cc: Gert Driesen; Nant-Developers (E-Mail)
Subject: Re: [nant-dev] Mono 1.0 / Using NAnt project for framework
discovery
Clayton,
I built from the release tarballs ( also 0.91 ) but that should be
pretty much the same as using red-carpet. Why did you have to move the
dlls ? What error did you get ?
Ian
Clayton Harbour wrote:
>
>I grabbed the rpms off of Red Carpet which give me version 0.91. For this
version I had to move the dlls in the lib/mono/1.0 directory up to the task
directory. Are we using different versions? Also changing the encoding of
the configuration file to UTF-8 gets around the xml exception, can this be
changed without causing problems elsewhere?
>
>
>Cheers,
>
>
>Clayton
>
>-----Original Message-----
>From: Ian MacLean [mailto:[EMAIL PROTECTED]
>Sent: Wed 5/5/2004 12:34 AM
>To: Gert Driesen
>Cc: Nant-Developers (E-Mail)
>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.h
tm
>>>
>>>
>>>
>>>
>>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
