Re: [Mono-dev] [Patch] xbuild, ResXFileRef and relative windows paths
On Sun, Mar 22, 2009 at 12:24 PM, Leszek Ciesielski wrote: > I agree with Gert, either xbuild has to restrict the path separator > substitution to cases where a file before substitution can not be > found and after substitution it is found, or, IMHO a better solution, > xbuild wrapper script (i.e. the /usr/bin/xbuild itself) should set > MONO_IOMAP before exec'ing mono instead of replicating such hacks > across multiple Microsoft.Build.* classes. Bear in mind that custom > (user-provided) tasks will most likely exhibit this problem as well. > > On Sun, Mar 22, 2009 at 8:48 AM, Gert Driesen wrote: >> Daniel, >> >> I'm ok with the change, but why not just use MONO_IOMAP? >> Will you only replace the Windows directory separator if the file could not >> be found? >> We should continue to support backslashes in unix paths. >> >> When we start adding such compatibility hacks in multiple class libraries / >> tools, then it may be a good time to reconsider implementing it in the >> runtime. Microsoft.Build.* classes might be used from applications like MonoDevelop, not just xbuild.exe. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] xBuild - metadata in conditions
On 6/19/07, Michael CATANZARITI <[EMAIL PROTECTED]> wrote: > Hi, > > I would like to implement metadata in conditions in xBuild. > For instance : > > > > > A > > > > > A > > > B > > > A > > > > > Condition="'%(group)'=='$(copygroup)'" SourceFiles="@(myfiles)" > DestinationFolder="C:\Temp" SkipUnchangedFiles="true" /> > > > > > Has someone already begun working on this feature ? Or at least has a design > idea ? > > Thank you, > > Michaël I don't think that anyone started work on this. There is specification on msbuild wiki (channel9 -> msbuild) "ComplexConditionSpecification". It will require quite a lot of work (it may be needed to rewrite/refactor most of the code that parses expressions in xml attributes) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Private version of C5 / Mono XBuild Problems
On pon, 2007-05-07 at 00:03 +0300, Dan Shechter wrote: > Hi, > I have a privately compiled version of C5, since I need it both of > Microsoft .NET framework and in Mono. > > My .csproj files contain the proper reference: > > > False > ..\..\deplibs\C5.dll > It's caused by processorArchitecure=MSIL. I'm using AssemblyName's ctor to get AssemblyName from string. I already sent patch to the list (I think it's simple but it's mono runtime so it needs review): http://lists.ximian.com/pipermail/mono-devel-list/2007-May/023403.html. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] AssemblyName.ctor () can't parse ProcessorArchitecture.
I know that AssemblyName.ProcessorArchitecture isn't used in Mono but
I'm using AssemblyName.ctor in xbuild (to build AssemblyName from
string) and current version throws exception when it sees
"ProcessorArchitecture=something".
Here's a patch that makes it assign correct values to new field in
MonoAssemblyName.
--
Marek Sieradzki <[EMAIL PROTECTED]>
Index: mono/metadata/assembly.c
===
--- mono/metadata/assembly.c (wersja 76761)
+++ mono/metadata/assembly.c (kopia robocza)
@@ -1618,7 +1618,7 @@
}
static gboolean
-build_assembly_name (const char *name, const char *version, const char *culture, const char *token, const char *key, MonoAssemblyName *aname, gboolean save_public_key)
+build_assembly_name (const char *name, const char *version, const char *culture, const char *token, const char *key, const char* cpu_arch, MonoAssemblyName *aname, gboolean save_public_key)
{
gint major, minor, build, revision;
gint len;
@@ -1681,6 +1681,18 @@
g_free (pkey);
}
+ if (cpu_arch) {
+ if (g_ascii_strcasecmp (cpu_arch, "MSIL") == 0)
+ aname->processor_architecture = 1;
+ else if (g_ascii_strcasecmp (cpu_arch, "X86") == 0)
+ aname->processor_architecture = 2;
+ else if (g_ascii_strcasecmp (cpu_arch, "IA64") == 0)
+ aname->processor_architecture = 3;
+ else if (g_ascii_strcasecmp (cpu_arch, "Amd64") == 0)
+ aname->processor_architecture = 4;
+ else
+ return FALSE;
+ }
return TRUE;
}
@@ -1696,7 +1708,7 @@
return FALSE;
}
- res = build_assembly_name (name, parts[0], parts[1], parts[2], NULL, aname, FALSE);
+ res = build_assembly_name (name, parts[0], parts[1], parts[2], NULL, NULL, aname, FALSE);
g_strfreev (parts);
return res;
}
@@ -1709,6 +1721,7 @@
gchar *culture = NULL;
gchar *token = NULL;
gchar *key = NULL;
+ gchar *cpu_arch = NULL;
gboolean res;
gchar *value;
gchar **parts;
@@ -1755,12 +1768,18 @@
tmp++;
continue;
}
+
+ if (!g_ascii_strncasecmp (value, "ProcessorArchitecture=", 22)) {
+ cpu_arch = g_strstrip (value + 22);
+ tmp++;
+ continue;
+ }
g_strfreev (parts);
return FALSE;
}
- res = build_assembly_name (dllname, version, culture, token, key, aname, save_public_key);
+ res = build_assembly_name (dllname, version, culture, token, key, cpu_arch, aname, save_public_key);
g_strfreev (parts);
return res;
}
Index: mono/metadata/image.h
===
--- mono/metadata/image.h (wersja 76761)
+++ mono/metadata/image.h (kopia robocza)
@@ -23,6 +23,7 @@
guint32 hash_len;
guint32 flags;
guint16 major, minor, build, revision;
+ guint32 processor_architecture;
} MonoAssemblyName;
typedef enum {
Index: mono/metadata/object-internals.h
===
--- mono/metadata/object-internals.h (wersja 76761)
+++ mono/metadata/object-internals.h (kopia robocza)
@@ -946,6 +946,7 @@
MonoArray *keyToken;
guint32 versioncompat;
MonoObject *version;
+ guint32 processor_architecture;
} MonoReflectionAssemblyName;
typedef struct {
Index: mono/metadata/icall.c
===
--- mono/metadata/icall.c (wersja 76761)
+++ mono/metadata/icall.c (kopia robocza)
@@ -4502,6 +4502,8 @@
p++;
}
}
+
+ aname->processor_architecture = name->processor_architecture;
}
static void
Index: class/corlib/Test/System.Reflection/AssemblyNameTest.cs
===
--- class/corlib/Test/System.Reflection/AssemblyNameTest.cs (wersja 76761)
+++ class/corlib/Test/System.Reflection/AssemblyNameTest.cs (kopia robocza)
@@ -748,6 +748,22 @@
Assert.IsNull (an, "Ctor6#9");
}
+ [Test]
+ public void TestProcessorArchitecture ()
+ {
+ AssemblyName a1 = new AssemblyName ("test, processorArchitecture=MSIL");
+ AssemblyName a2 = new AssemblyName ("test, processorArchitecture=msil");
+ AssemblyName a3 = new AssemblyName ("test, processorArchitecture=X86");
+ AssemblyName a4 = new AssemblyName ("test, processorArchitecture=IA64");
+ AssemblyName a5 = new AssemblyName ("test, processorArchitecture=Amd64");
+
+ Assert.AreEqual (ProcessorArchitecture.MSIL, a1.ProcessorArchitecture, "ProcessorArchitecture#1");
+ Assert.AreEqual (ProcessorArchitecture.MSIL, a2.ProcessorArchitecture, "ProcessorArchitecture#2");
+ Assert.AreEqual (ProcessorArchitecture.X86, a3.ProcessorArchitecture, "ProcessorArchitecture#3");
+ Assert.AreEqual (ProcessorArchitecture.IA64, a4.ProcessorArchitecture, "ProcessorArchitecture#4");
+ Assert.AreEqual (ProcessorArchitecture.Amd64, a5.ProcessorArchitecture, "ProcessorArchitecture#5");
+ }
+
#endif
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Wrong logs from make run-test-ondotnet
This patch fixes it. make.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need your help: Mainsoft/Novell "Race to Linux"
On sob, 2007-01-27 at 14:49 +0200, sasha wrote: > I think it would be very nice to port SharpDevelop 2.1 on mono :-) No, it wouldn't be nice because SharpDevelop was written as Windows program. You would need to rewrite really big part part of code. Maybe when SharpDevelop will more portable. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Winforms breakages under 1.2.3
On nie, 2007-01-28 at 23:58 +, Paul wrote: > Hi, > > I have an application built under VS.NET which runs fine. The code is > supported happily in Mono (there is nothing in it which causes it to > bork on compiling) > > I've hit the following problems > > (Under both Linux and Win32) > > Number 1 - password properties. > === > > password properties on a text box are broken. > > I have the following code > > this.tb_password.Enabled = false; > // set up the name and position > this.tb_password.PasswordChar = (char)'*'; > > Under 1.2.2, this would result in the tb_password textbox having all *'s > inside, under 1.2.3, it's plain text. > > Number 2. Resources problems > > > Images set using global::progname.Properties.Resources.filename are not > being recognised under 1.2.3 - not sure if they are under 1.2.2 (not > tested this sort of code before). Works fine under VS.NET. I think that you're using VS generated wrapper class that is accessing resources files. Could you make a simple project that only uses resources that way and attach it? -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] corlib tests broken under net_2_0 profile
Hi, as you can see here: http://pastebin.ca/288704 and in mono.ximian.com/monobuild -> x86 -> latest build -> test_profiles Mono writes some weird warnings and fails 2-4 tests in corlib. I'm not sure when it started to happen. I ran those tests on r69950. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NET_2_0 class status not available
On wto, 2006-12-12 at 13:18 +0100, Kornél Pál wrote: > Hi, > > BTW is the buildbot page (http://mono.ximian.com:8008/) retired? > Yes, but there are some old links left on Wiki. New address is http://mono.ximian.com/monobuild/ -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] class status 2.0
On 11/14/06, Matthijs ter Woord <[EMAIL PROTECTED]> wrote: > Are there plans to update the class status data files to the .NET 2.0 RTM > assemblies? > They are already .NET 2.0 RTM. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Microsoft.Build.* API fixes
On 10/20/06, Leszek Ciesielski <[EMAIL PROTECTED]> wrote: > On 10/20/06, Marek Sieradzki <[EMAIL PROTECTED]> wrote: > > On 10/20/06, Leszek Ciesielski <[EMAIL PROTECTED]> wrote: > > > On 10/20/06, Marek Sieradzki <[EMAIL PROTECTED]> wrote: > > > > On 10/20/06, Leszek Ciesielski <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > > > > > attached is a patch fixing minor attribute differences between mono > > > > > and ms.net, and containing stubs for (some of) missing classes. > > > > > Permission to commit? > > > > > > > > > Hi, > > > > > > > > AssemblyInfo.cs changes are questionable. If there's a good reason for > > > > them please specify it. > > > > > > Those attributes are present in MS.Net assembly ( consult eg. mono > > > class status). Other that that - none, I dubt mono supports them at > > > this time (meaning "pays any heed to them", I know compiler generates > > > them properly). It's just a small increase in compatibility, when I > > > could see no problems on our side. I do not want to argue, but if you > > > are against applying them, please specify a reason :-) > > > > > I asked Miguel some time ago about that. Mono is based on msdn + ecma > > docs. If specific attribute isn't obvious/needed nor documented it shouldn't > > be added. Or at least it's the way I understood it. > > Patch with the class stubs again. This time without changes to > assembly attributes and with correct (consistent with module style) > formatting. Also, this one contains two more stubs. Permission to > commit? Yes. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Microsoft.Build.* API fixes
On 10/20/06, Leszek Ciesielski <[EMAIL PROTECTED]> wrote: > On 10/20/06, Marek Sieradzki <[EMAIL PROTECTED]> wrote: > > On 10/20/06, Leszek Ciesielski <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > attached is a patch fixing minor attribute differences between mono > > > and ms.net, and containing stubs for (some of) missing classes. > > > Permission to commit? > > > > > Hi, > > > > AssemblyInfo.cs changes are questionable. If there's a good reason for > > them please specify it. > > Those attributes are present in MS.Net assembly ( consult eg. mono > class status). Other that that - none, I dubt mono supports them at > this time (meaning "pays any heed to them", I know compiler generates > them properly). It's just a small increase in compatibility, when I > could see no problems on our side. I do not want to argue, but if you > are against applying them, please specify a reason :-) > I asked Miguel some time ago about that. Mono is based on msdn + ecma docs. If specific attribute isn't obvious/needed nor documented it shouldn't be added. Or at least it's the way I understood it. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DebuggingAttribute and ComVisibleAttribute
On 10/19/06, Leszek Ciesielski <[EMAIL PROTECTED]> wrote: > Hi, > > attached is a small patch which makes those two attributes compatible > with net 1.1 and net 2.0. Permission to commit? > > Another thing: are such small incompatibilities intentional, or is > this just a mistake? Should I commit more of such 'API - > compatibility' fixes? > There are people who know more than me but: probably those incompatibilities should be fixed but no-one had time to do that. BTW your code doesn't follow coding guidelines. (ComVisible.cs already has weird casing for Visible (private field)). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Microsoft.Build.* API fixes
On 10/20/06, Leszek Ciesielski <[EMAIL PROTECTED]> wrote: > Hi, > > attached is a patch fixing minor attribute differences between mono > and ms.net, and containing stubs for (some of) missing classes. > Permission to commit? > Hi, AssemblyInfo.cs changes are questionable. If there's a good reason for them please specify it. Small coding style glitch. You are using "F()" instead of "F ()" VCBuild is a class that rather won't be implemented. In MSBuild it executes VS C++ build (that uses different format of project files). It is possible that someone can use gcc/g++ for that but generally I'm not sure if anyone will use it. Anyway monotodo + notimplementedexception stub can be added. Vbc task should be quite easy to write when we'll have it working on Mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] We broke nant... again.
On 10/19/06, Leszek Ciesielski <[EMAIL PROTECTED]> wrote: > Hi, > > on 14th of October a new nant version was released, fixing some bugs > that were encountered when running on mono 1.1.17. On 16th mono 1.1.18 > was released, breaking nant - again. It is able to compile itself, but > falls into an endless loop (seemingly in mono XML parser) when being > run on more complex build files, with many 'include's and complex > 'depends' attributes. Just downgrade mono until nant is fixed. > > I am thinking (again) about dumping nant completely and switching to > (ms/x)build. But as I tried to build a simple VS2005 project today I > run into several problems. > > First: xbuild does not seem to support .sln files at all. This can be > worked around by generating a .proj file from .sln in msbuid, or , for > single-project solutions, using just the project file. MS is autogenerating a .csproj file from .sln just before the build. It's a simple target that uses MSBuild task. It can done the same way in xbuild. What you also need are working cross project references. It's still not working in xbuild. > > Second: xbuild does not know the implicit targets defined in msbuild, > like Rebuild or Clean (and probably others). Someone should write them and test them. > > Third: xbuild does not work on windows. Well, it runs, but cannot > compile anything. This is because to bug 79263 ( > http://bugzilla.ximian.com/show_bug.cgi?id=79263 ). It won't change soon. Until it's fixed you can use msbuild. > > While first and third problems are not critical, the second one is... > Anyone knows a solution (besides downgrading to mono 1.1.17) ? > Beside that my computer is temporarily broken (happening quite often to me) xbuild needs more work in the core. MSBuild consists of: framework + engine + common files + user projects. At the moment core (Microsoft.Build.Engine) needs more NUnit tests. When something goes wrong (anywhere from the components list) new users don't have patience to fix the bugs. Also I don't have a lot of time recently. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Sharing build specs between MS VS .net 2005 and monoon Linux
On 9/15/06, Michael Jerris <[EMAIL PROTECTED]> wrote: > > From: [EMAIL PROTECTED] > [mailto:mono-devel-list- > > [EMAIL PROTECTED] On Behalf Of Mads Bondo Dydensborg > > Sent: Friday, September 15, 2006 11:13 AM > > To: mono-devel-list@lists.ximian.com > > Subject: Re: [Mono-dev] Sharing build specs between MS VS .net 2005 > and > > monoon Linux > > > > > > > > Optimally, xbuild would support new msbuild format files, and > > > switching between mono and ms.net would be a complete no brainer :-) > > > > Yes, this would be ideel. I am not a big MS fan myself, but it seems > that > > MSBuild is a sensible system (inspired by nant, apparently). Having a > > compatible crossplatform tool for mono would appear to be a good > thing. > > Especially since this would allow the Windows developers to remain in > > Visual > > Studio all the time, which appears to be a high priority for them... > > Another interesting tool to look at would be bakefile. I don't believe > it has mono support at this point, but it seems to be approaching the > same sort's of issues, and already has quite a bit of support for visual > studio and makefiles and several other output types. I like their > approach. This is the build tool being developed for WxWidgets. > NAnt should be used until xbuild is usable. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Documentation synchronization
On 9/15/06, Jacob Ilsø Christensen <[EMAIL PROTECTED]> wrote: > Hi. > > On 9/15/06, Michael Schurter <[EMAIL PROTECTED]> wrote: > > Hi Jacob, > > > > Jacob Ilsø Christensen wrote: > > > Hi again. > > > > > > Just out of curiosity. Why was this documentation approach chosen as > > > opposed to e.g. source code doc comments? > > > > > > A big advantage of source code doc comments is that they are available > > > as you do the actual coding. With the current approach you have to > > > look in a separate xml file to see documentation for a specific class > > > or method or did I miss out on something? > > > > If I remember correctly its to make translation easier. Please don't > > top post. > > > > So code documentation is actually translated in mono? > No but there is "en" folder. It doesn't make any sense to me to translate mono documentation to other languages as the English version is not complete. But if someone wants to do it's possible. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Case sensitivity and xbuild
Hi, Some IDEs when making a new project add a reference to "Microsoft.CSharp.targets" and some to "Microsoft.CSharp.Targets". Of course under Linux you need to convert the name or install both files. In mcs/tools/xbuild/Makefile there's already line that installs "Microsoft.CSharp.targets". What should I add/change to install the file with another name without having to keep 2 files in svn? (I think that it would create some problems under Windows then) Copying A to B and installing B as it was done with A looks like a best thing to do. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Prj2make
Hi. I wanted to make some changes in MonoDevelop's prj2make but I saw that prj2make is also in Mono. Code is a bit different (one file more in mono). Shouldn't the part that can be put into library be a library (Mono.Prj2make)? I think that I want to be mantainer of prj2make. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compile mono in FC5
On pią, 2006-07-21 at 10:08 +0800, ZhangZQ wrote: > Hi, > > I checkout the source from SVN and compile it under FC5 with gcc-4.1.1-1, > and I installed the mono 1.1.13.7 that come with FC5. I used this command to > build mono 'make get-monolite-latest;make EXTERNAL_MCS=false' to build mono, > but got the error, > > Making all in net_2_0 > make[3]: Entering directory `/home/zzq01/source/mono/mono/data/net_2_0' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory `/home/zzq01/source/mono/mono/data/net_2_0' > make[3]: Entering directory `/home/zzq01/source/mono/mono/data' > make[3]: Nothing to be done for `all-am'. > make[3]: Leaving directory `/home/zzq01/source/mono/mono/data' > make[2]: Leaving directory `/home/zzq01/source/mono/mono/data' > Making all in runtime > make[2]: Entering directory `/home/zzq01/source/mono/mono/runtime' > if test -w ../../mcs; then :; else chmod -R +w ../../mcs; fi > cd ../../mcs && make PROFILES='default net_2_0' CC='gcc' all-profiles > make[3]: Entering directory `/home/zzq01/source/mono/mcs' > make profile-do--default--all profile-do--net_2_0--all > make[4]: Entering directory `/home/zzq01/source/mono/mcs' > make PROFILE=basic all > make[5]: Entering directory `/home/zzq01/source/mono/mcs' > make[6]: *** [build/deps/basic-profile-check.exe] Error 1 > make[6]: Entering directory `/home/zzq01/source/mono/mcs' > *** The compiler 'false' doesn't appear to be usable. > *** Trying the 'monolite' directory. > make[7]: Entering directory `/home/zzq01/source/mono/mcs' > mono: mono-codeman.c:257: new_codechunk: Assertion `!err' failed. > make[8]: *** [build/deps/basic-profile-check.exe] Aborted > make[8]: Entering directory `/home/zzq01/source/mono/mcs' > *** The contents of your 'monolite' directory may be out-of-date > *** You may want to try 'make get-monolite-latest' > make[8]: *** [do-profile-check-monolite] Error 1 > make[8]: Leaving directory `/home/zzq01/source/mono/mcs' > make[7]: *** [do-profile-check] Error 2 > make[7]: Leaving directory `/home/zzq01/source/mono/mcs' > make[6]: *** [do-profile-check-monolite] Error 2 > make[6]: Leaving directory `/home/zzq01/source/mono/mcs' > make[5]: *** [do-profile-check] Error 2 > make[5]: Leaving directory `/home/zzq01/source/mono/mcs' > make[4]: *** [profile-do--basic--all] Error 2 > make[4]: Leaving directory `/home/zzq01/source/mono/mcs' > make[3]: *** [profiles-do--all] Error 2 > make[3]: Leaving directory `/home/zzq01/source/mono/mcs' > make[2]: *** [all-local] Error 2 > make[2]: Leaving directory `/home/zzq01/source/mono/mono/runtime' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/zzq01/source/mono/mono' > make: *** [all] Error 2 > > > then I used 'make' to build again, still got the error > make all-local > make[8]: Entering directory `/home/zzq01/source/mono/mcs/class/System' > ** Warning: System.dll built without parts that depend on: System.Xml.dll > make[8]: Leaving directory `/home/zzq01/source/mono/mcs/class/System' > make[7]: Leaving directory `/home/zzq01/source/mono/mcs/class/System' > make[7]: Entering directory `/home/zzq01/source/mono/mcs/class/System.XML' > make all-local > make[8]: Entering directory `/home/zzq01/source/mono/mcs/class/System.XML' > MONO_PATH="../../class/lib/basic:$MONO_PATH" > /home/zzq01/source/mono/mono/runtime/mono-wrapper > ../../class/lib/basic/mcs.exe > /codepage:28591 -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug > /noconfig -r:mscorlib.dll -r:System.dll -nowarn:0162,0618,0612,0642,1595 > -target:library > -out:System.Xml.dll System.Xml.XPath/Parser.cs > Mono.Xml.Xsl/PatternParser.cs Mono.Xml.Xsl/PatternTokenizer.cs > @System.Xml.dll.sources > mono: mono-codeman.c:257: new_codechunk: Assertion `!err' failed. > make[8]: *** [../../class/lib/basic/System.Xml.dll] Aborted > make[8]: Leaving directory `/home/zzq01/source/mono/mcs/class/System.XML' > make[7]: *** [do-all] Error 2 > make[7]: Leaving directory `/home/zzq01/source/mono/mcs/class/System.XML' > make[6]: *** [all-recursive] Error 1 > make[6]: Leaving directory `/home/zzq01/source/mono/mcs/class' > make[5]: *** [all-recursive] Error 1 > make[5]: Leaving directory `/home/zzq01/source/mono/mcs' > make[4]: *** [profile-do--basic--all] Error 2 > make[4]: Leaving directory `/home/zzq01/source/mono/mcs' > make[3]: *** [profiles-do--all] Error 2 > make[3]: Leaving directory `/home/zzq01/source/mono/mcs' > make[2]: *** [all-local] Error 2 > make[2]: Leaving directory `/home/zzq01/source/mono/mono/runtime' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/zzq01/source/mono/mono' > make: *** [all] Error 2 > > > I can successfully compile the mono source from SVN in FC4 with gcc 4.0.2-8. > has somebody successfully compiled mono in FC5? > It's obvious that EXTERNAL_MCS=false makes it treat "false" as C# compiler. Remove that variable or change it to something useful. ___ Mono-devel-list mailing list Mono
Re: [Mono-dev] We want to contribute
On pon, 2006-07-17 at 15:01 -0400, Jesse Guardiani wrote: > Andrés G. Aragoneses [ knocte ] wrote: > > Martin Hinks escribió: > >> My main gripe with MonoDevelop is that the official IDE > >> for cross-platform .NET is not cross-platform. > > > > Yes, that's the same thing I claimed when I wrote "nowadays, it is very > > difficult to convince people about using a multiplatform development > > tool whose own IDE is not multiplatform". > > > > Regards. > > > > Andrés [ knocte ] > > > > -- > > I understand the concern, but isn't mono very comparable to a Java VM? > Of course, it includes a huge open source class library too, but it > seems to be very similar to the way Java has multiple VMs (IBM, Sun, MS, > Blackdown, etc). > > I think people just aren't used to thinking of .NET as a technology like > Java. They prefer to think of it as some mysterious thing from Microsoft. > > In that light, it makes sense to not write an IDE for win32 as the win32 > folks already have a ton of their own IDEs. But, then again, we made > mono itself run on win32, so why not the mono IDE? As John Luke said it wasn't a goal for the MonoDevelop. If someone wants to do that his work will be probably approved. But it's really a lot of work to do. It's easy to discuss about what needs to be done. But when the work needs to be done MonoDevelop on Windows topic gets completely silent after a week. :) I think that I see this topic every year. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Single thread scheduler for Threading.Timers patch
On Tue, 2006-06-13 at 23:04 -0700, Rafael Ferreira wrote: > Howdy, > > The attached patch changes the current Threading.Timer class to use a > single thread scheduler instead of the current 1 thread per timer logic. > I also spent a lot of time working on the Timer unit tests so they more > consistently pass as well as fixing the "NotWorking" tests. > > Some key features include: > > * A single thread handles firing all timer jobs thus allowing a much > greater number of Timers to be defined - Fixing bug #65734 > * Timer scheduler is only started after the first System.Threading.Timer > is created (lazy init) > * Timer scheduler thread dies if there are no more timer jobs in its Job > queue (early termination) > * Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG > environment variable > > Of course, I don't expect this patch to be accepted without some degree > of scrutiny so comments/concerns are appreciated and I can commit the > code once we're all comfortable with it. > You are using wrong coding style in some places (f() instead of f ()). -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Variant patch
Dnia 05-06-2006, pon o godzinie 23:27 -0400, Jonathan S. Chambers napisał(a): > Here is the previous patch plus an incremented corlib, ChangeLog entries, and > a series of tests for both BSTR and VARIANT marshalling on windows. You have changed formatting in mcs/class/corlib/System.Runtime.InteropServices/Marshal.cs (GetComSlotForMethodInfo ()) (btw to wrong format). -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cross-platform: msbuild and xbuild
Dnia 11-05-2006, czw o godzinie 22:01 -0400, Karl Waclawek napisał(a): > When I heard about xbuild I thought its purpose was to allow for sharing > project files between MS.NET and Mono. > As I would like to release source code for both platforms with minimal > build differences this would be very handy. > > However, it appears that this does not work. Is my assumption mistaken? > Implementing MSBuild is complicated task. You're right about your assumption but getting xbuild to work like MSBuild will take some time. If you're looking for a workaround you can use NAnt addin for Visual Studio. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] xbuild + Microsoft.Build.Engine.dll + Bugs
Dnia 02-05-2006, wto o godzinie 14:54 -0500, [EMAIL PROTECTED] napisał(a): > I have a couple small bugs/patches for xbuild.exe and > Microsoft.Build.Engine.dll, but there doesn't appear to be the appropriate > "Products" to place them under. > > Thoughts? > There is no entry in bugzilla but you can add it to tools section or post patches here or send me them. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Class status
Dnia 21-04-2006, pią o godzinie 09:29 +0200, Matthijs ter Woord napisał(a): > Hi, > > > Why is the class status for the 2.0 profile still compared to the > MS .NET framework 2.0 Beta 2 release? The RTM release of MS.NET 2.0 is > out for quite some time now. > It is compared to 2.0 not 2.0 Beta 2. I'm sure of that in case of Microsoft.Build.*. Probably other assemblies use the same revision. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] Some bugs in xbuild and DirectorySeparator.
Dnia 11-03-2006, sob o godzinie 07:56 +0200, Crestez Leonard napisał(a): > I fixed some bugs in xbuild. > > First, there's no reason for BuildItem.GetMetadata to always fail when > the file doesn't exist, msbuild doesn't do that. Stuff that only relies > on the path should work. > > I also modified DirectoryScanner a lot. It used to reorder multiple > includes and fail on duplicates. msbuild doesn't do either. I didn't know that it failed on duplicates and forgot to place FIXME for reordering (caused by hashtable). > > The patch is from a svn diff in the root mcs dir. > > Right now xbuild won't work with msbuild projects because of path > separator problems. A patch to make xbuild take both / and \ as path > separators should be easy to write, but it's ugly. On the other hand > current behaviour makes xbuild useless. Will you accept the patch if I > write it? Yes. I wondered what should I do about strings like "a\b". Should I search for '\' and replace with '/' or make switch to xbuild.exe or what else. BTW there are way more reasons why xbuild won't run VS2005 project files. > > Also, I noticed that in mono both Path.DirectorySeparatorChar and > Path.AltDirectorySeparatorChar are /, while msdn says on unix they > should be / and \. I know monodoc says they're both /, but why? > I'm really excited of that someone tried to fix this mess. Also it would be great not to duplicate work. I'm synchronizing my local changes with SVN today. Could you send the patch? -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Fwd: Planning for Mono 1.2: API freeze.]
Dnia 02-01-2006, pon o godzinie 12:55 -0500, Miguel de Icaza napisał(a): > Załącznik: wiadomość e-mail, "Forwarded message - Planning for Mono > 1.2: API freeze." > > Przesyłany list -- > > Od: Miguel de Icaza <[EMAIL PROTECTED]> > > Dla: Mono Hackers <[EMAIL PROTECTED]> > > Temat: Planning for Mono 1.2: API freeze. > > Data: Mon, 02 Jan 2006 12:54:19 -0500 > > > > Hello folks, > > > > I know that this is a very short notice, I should have mentioned > > this in mid-December, but I completely blanked out. > > > > We are going to API freeze Mono this week. If you have any API > > changes that you want to make, please contact me directly. > > > > What this means is that the public API of the Mono-specific > > libraries will cease to change, although we can continue to bug fix it > > and document it. > > > > The .NET libraries already had their APIs set in stone, so those > > will continue to be developed (implementing NotImplementedExceptions, > > fixing bugs and implementing NET_2_0 protected code). > > > > Changes to the .NET public API to fix differences against the > > published .NET interface is ok (specially in the 2.x universe, as Mono > > 1.2 will not guarantee .NET 2.0 support in full anyways, so things are > > much more lax there). > > > > So in short: you can change implementation bits, but not public > > interfaces. > > > > If an API change is /absolutely required/ this needs to be discussed > > before the patch makes it into SVN. API from NET 2.0 (Microsoft.Build.*) isn't considered stable? Code that is currently in SVN was obsoleted by new NET 2.0 release and it needs some changes. There is absolutely no compatibility between these two versions (from Beta 2 and 2.0). I added some code to new Mono.XBuild namespaces. I think that something of it can also change to make it work with 2.0 Microsoft.Build. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] building for Mono under msbuild
Dnia 11-10-2005, wto o godzinie 11:49 -0700, Andy Waddell napisał(a): > I have an application that needs to run under both .NET and Mono and I > came up with a pretty simple way to get MS DevStudio to build both. I > don’t know how others have solved this problem, but I thought I would > offer it up in case it helps someone else with the same issue. The > basic approach I took was to call the Mono compiler after the > Microsoft build has already run. Microsoft has a well known target > “AfterBuild” which I have hooked to invoke gmcs with pretty much the > same arguments that csc.exe takes with some minor modifications. I > put all the Mono build stuff in a file called Mono.targets, so it only > take a one line addition to the standard *.csproj file to get the > functionality: > > > > > > Add this lineà Few weeks before this post someone sent post with his .targets file. It should be in the archive. (I don't know if attachment is also archived) > This will make your build essentially a dual pass build with all the > Microsoft stuff running and then the Mono compiler running with all > the warnings and erros showing up in the IDE as you would expect. The > work is not complete (I don’t pass all the options possible, etc), but > I think it’s fairly obvious how to expand it if needed. > > > > I’m sure there are many other ways to skin this cat, but for a quick > and dirty solution, it seems to work pretty well. > > > > ToDo: invesitgate xbuild to do my Linux builds. > Current xbuild won't build project from .csproj file because some features use by Microsoft.Common.targets are not implemented and because of that this .targets file is not made for Mono but Microsoft .NET runtime. At this moment it should be possible to use mcs by Microsoft.Build.Tasks.Csc from xbuild. You would need to load it (UsingTask) and create your own version of Compile target. You need to be sure that VS does not use HostObject(Microsoft.Build.Tasks.Hosting.ICscHostObject) compiler which is implemented in VS2005 but not in MSBuild or xbuild. I'm working on rewrite in xbuild. When I'll get some free time I'll write more tests and fix bugs. (like AL task that isn't reporting errors/warnings properly) -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MSBuild target for Mono
Builds inside VS2005 use Microsoft.Build.Tasks.Hosting.ICscHostObject interface. Microsoft.Build.Tasks.Csc class is also used for builds. To use mcs instead of csc you need to write your own Csc task with ie. CscHostObject. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Targets file to aid in Mono development on Visual Studio 2005 Beta 2
Dnia 23-08-2005, wto o godzinie 16:28 -0700, Mike Hull napisał(a): > Hello, > > Attached is a file that we use for our cross platform development. It > allows us to build a Linux or Mono release from Visual Studio .NET > 2005 that targets the Mono class libraries including mscorlib in the > same solution as our .NET 1.1 and .NET 2.0 targets. For those of you > who are developing cross platform C# and you are using Visual Studio > 2005 Beta 2 as an IDE, this file will probably be useful. > > To use it change the line in your csproj file: > > > > To: > > > > This needs to be done in each project file in your solution. Also you > may need to adjust the installation path for your mono setup, in the > targets file. > > Once this is done, load up your solution/project. You should notice > under the Solution platforms you have Linux, Mono 2.0, .NET 1.1, and > Any CPU. > * Linux and Mono are basically the same. They just differ in > the DefineConstants. > * .NET 1.1 is to target the old .NET runtime. > * Any CPU is your standard .NET 2.0 target. That file will be useful in XBuild. I was having problems with .targets file mainly because Microsoft.CSharp.targets is .NET/Microsoft specific. However it can be used for real things only when XBuild will have condition support. I'm currently dealing with various tasks like Csc. You can look into Mono anonymous SVN module 'xbuild'. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] reduced size package
Dnia 24-06-2005, pią o godzinie 10:27 +0100, Andrew napisał(a): > Hi everyone > > I'm new to the list, residing in the UK and trying to get a small .NET > application to run correctly under MONO. > > At present my question is about the possibility of using a small part of > MONO. > > The .NET application I wish to deliver by download is very simple, and > must surely use only a very small part of the MONO runtime. Is it > possible to put together a package which contains only that much of the > MONO runtime that this program needs? Well, ok, anything is possible, > but is it readily doable, or even feasible? I have a certain amount of > C/UNIX programming experience, but no real experience of deploying > sofware to market and making it available to run on different platforms. > > I have searched the archives, but found nothing of relevance, but my > apologies if the question has already been addressed. > Mono has list of ideas for Google SOC. http://www.mono-project.com/StudentProjects/ There is a plan to use Cecil when making tool that can create such small binaries. It will be called "Linker Tool for CIL". In a few days we will know whether someone will be making this. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] MonoDevelop : looking for mozilla
Dnia 23-06-2005, czw o godzinie 16:22 +0200, Mikkel Kruse Johnsen napisał(a): > Hi > > No it is not possible to use firefox, firefox is compiled in static mode, > and gecko-sharp needs a shared compiled mode. Witch mozilla is. You mean firefox from www.mozilla.org site? I mean ie. mozilla-firefox package in Ubuntu. In my case it works. (gecko-sharp from svn). I guess mozilla-firefox was compiled to shared binaries. > > > I think there is a way. Just set MOZILLA_FIVE_HOME environment variable > > to path where you have Firefox. > > Dnia 23-06-2005, czw o godzinie 09:49 +0100, Martin Hinks napisał(a): -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] MonoDevelop : looking for mozilla
I think there is a way. Just set MOZILLA_FIVE_HOME environment variable to path where you have Firefox. Dnia 23-06-2005, czw o godzinie 09:49 +0100, Martin Hinks napisał(a): > I believe the answer is no, you have to install Mozilla. > > Martin > > On 6/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi, > > > > When I launch Monodevellop, I get this message : > > > > which: no mozilla in > > (/usr/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/home/maitrebn/bin) > > Cannot find mozilla installation directory. Please set MOZILLA_FIVE_HOME to > > your > > mozilla directory > > > > ... > > > > Is there a way to use Monodevelop with FireFox ? > > > > ___ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] MSBuild implementation and Google Summer of code
I'm going to send application to google for this. I have some questions. 1. On what license code from svn.myrealbox.com/monodevelop/trunk/MSBuild/ is released? I have used it for start. I have made stubs for remaining classes, interfaces, delegates and enums that are in namespaces Microsoft.Build.Engine, Microsoft.Build.Framework, Microsoft.Build.Tasks, Microsoft.Build.Utilities. 2. Am i right with that: MSBuild implementation should consist of 3 parts: xml parser(using XmlSerializer), classes from 4 above mentioned namespaces and a command line tool? 3. Which documentation should I use? There are(in MSDN): .NET Framework reference about Longhorn and some notes about msbuild app. 4. What about methods typical to Win32 API? Like Microsoft.Build.Utilities.ToolLocationHelper.GetDotNetFrameworkRootRegistryKey(). 5. Is anyone able to contact with Rob Tillie <[EMAIL PROTECTED]>? He started the implementation that is available in svn/md. -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
