Re: [Mono-dev] Repeat builds of core assemblies
kudos to you, Miguel! On Fri, May 2, 2014 at 5:27 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello guys, Just a follow up to my previous posting on this. I have managed to untangle this mess, and now I have a clean build that does not involve overwriting assemblies. In addition to untangling this, I added dependencies on all the assemblies involved in this circular dependency mess so if you type make in any of System, System.Xml, System.Security, Mono.Security or System.Configuration, all the dependencies will be properly built. During the fixing, I noticed that our System.Xml build must have broke a few eons ago, because there was code in place to perform a 2-stage System.Xml build as well (without and with System.Configuration support), but nobody noticed that this had happened. While I fixed this, it raises the obvious point that nobody really cares (or likes) System.Configuration. While doing this review, I found a few other places that also have these ugly loops, so I am going to be fixing those as well. Miguel On Tue, Apr 22, 2014 at 3:53 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, I was looking at making the MSBuild system work, and during the process I have encountered a few problems that we have in our existing build system that are problematic. The problem is that System, System.XML and System.Configuration are each defined in terms of the other assemblies. So we gradually bring up each one of those assemblies up by first compiling a stub System, which we use to build System.XML and System.Configuration. Then we rebuild System, this time referencing System.XML and System.Configuration so we can take a dependency on them, and so on. To build a complete System.dll for a particular profile (net_2_0, net_4_0, etc) takes three steps: Core Build Secondary Build: Core Build + Defines: XML_DEP + SECURITY_DEP Refs: -r:PrebuiltSystem=../lib/Previous/System.dll -r:System.Xml.dll -r:MonoSecurity=Mono.Security.dll Final Build: Secondary Build + defines: -d:CONFIGURATION_DEP Refs: System.Configuration.dll The above is what is required to bring up System. Our implementation has one major problem: it overwrites the intermediate files. So the core build output is overwritten by the secondary build, and the secondary build is overwritten by the final build. It seems that historically, instead of introducing temporary directories for each stage, instead we hacked our way out of it. We introduced a LIBRARY_USE_INTERMEDIATE_FILE whose sole purpose was to work around the case where Windows was actively telling us we were doing something wrong (we were overwriting a file that we were actively referencing!) The above is also likely going to prevent reliable parallel builds, or probably means that we introduced some gross hack to make the above work in parallel. I am going to try to fix this, but the Makefile goop is pretty dense, and I might fail. I just figured I should share my findings in case civilization comes to an end and a future archeologist tries to figure out why this was not working. These are the defines that we use to bring up System for each profile: basic Profile: basic: -d:NET_1_1 -d:NET_2_0 -d:BOOTSTRAP_BASIC -d:CONFIGURATION_2_0 basic: -d:NET_1_1 -d:NET_2_0 -d:BOOTSTRAP_BASIC -d:CONFIGURATION_2_0 -d:XML_DEP Build Profile: build: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:CONFIGURATION_2_0 build: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:CONFIGURATION_2_0 -d:XML_DEP Net 2.0 profile: net_2_0: -d:NET_1_1 -d:NET_2_0 -d:CONFIGURATION_2_0 net_2_0: -d:NET_1_1 -d:NET_2_0 -d:CONFIGURATION_2_0 -d:XML_DEP -d:SECURITY_DEP net_2_0: -d:NET_1_1 -d:NET_2_0 -d:CONFIGURATION_2_0 -d:XML_DEP -d:SECURITY_DEP -d:CONFIGURATION_DEP Net 4.0 profile: net_4_0: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:CONFIGURATION_2_0 net_4_0: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:CONFIGURATION_2_0 -d:XML_DEP -d:SECURITY_DEP net_4_0: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:CONFIGURATION_2_0 -d:XML_DEP -d:SECURITY_DEP -d:CONFIGURATION_DEP Net 4.5 profile: net_4_5: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:NET_4_5 -d:CONFIGURATION_2_0 net_4_5: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:NET_4_5 -d:CONFIGURATION_2_0 -d:XML_DEP -d:SECURITY_DEP net_4_5: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:NET_4_5 -d:CONFIGURATION_2_0 -d:XML_DEP -d:SECURITY_DEP -d:CONFIGURATION_DEP Miguel ___ 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
Re: [Mono-dev] Recent C# compiler changes
On Thu, Feb 3, 2011 at 2:06 PM, Miguel de Icaza mig...@novell.com wrote: ... Is it possible to instead of using a set of preconfigured numbers for the SDK, that we could provide a string, so that: -sdk:STRING Makes mcs look in $prefix/lib/mono/STRING That way we do not hardcode the constant, and we can have different profiles just by building that directory and invoking the compiler with that option. +1 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building boo 0.9.2-3383 or 0.9.3-3457 problem
Hi! On Sat, Feb 20, 2010 at 9:21 PM, Paul p...@all-the-johnsons.co.uk wrote: ... Any ideas if it's me or not? It's a bug: http://jira.codehaus.org/browse/BOO-1282 The workaround is to remove any existing Boo.Lang.Extensions from the gac before building. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Passing values into the default.build boo script
On 6/7/06, PFJ [EMAIL PROTECTED] wrote: Hi, Hi! Is there a way to pass values into the default.build script for boo-0.7.6.2237? Yes, you can use -D:propertyName=propertyValue and override any properties you want. I'm packaging it for Fedora Extras... Great. Thanks! -- bamboo *** See you at the first global db4o User Conference in London, July 10 and 11, 2006 *** http://www.db4o.com/about/productinformation/events/duc2006/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Please, share your .Net1.1 and 2.0 support and #if directives experience
On 2/10/06, Francisco Figueiredo Jr. [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
Hey!
Npgsql developers are going to start adding 2.0 functionality and
interfaces to Npgsql.
We discussed about it and we decided to have another directory in Npgsql
cvs tree to hold the new Npgsql2 source code.
I'd like to hear from you what are your experience with usage of #if in
the source code.
...
We've been using #if directives with success for some time now for the
db4o code base. The main benefit is that the code is always where you
expect it to be.
For complex scenarios we use a mix of partial classes and #if
directives, for instance:
// Baz.cs
namespace Foo.Bar
{
#if NET_2_0
partial
#endif
class Baz
{
... // code for all platforms goes here
}
}
// Baz_2.cs
namespace Foo.Bar
{
#if NET_2_0
partial class Baz
{
// Net 2 specific code here
}
#endif
}
I would recommend against using #if directives inside a method body,
it's much better to have two versions of the method using 'Extract
Method' as appropriate to share functionality.
Rodrigo
PS: E aê, Chicão??!!! :)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C# and SWT
On 10/20/05, Elan Feingold [EMAIL PROTECTED] wrote: ... And then there's the IKVM project, which seems to be able to run Eclipse (and thus SWT) under Mono's VM -- but I'm not sure if that means I can write C# code that uses SWT. Yes. It works. bamboo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
SOLVED: Re: [Mono-devel-list] Patch for generating debug info in System.Reflection.Emit
On 7/28/05, Rodrigo B. de Oliveira [EMAIL PROTECTED] wrote: On 7/28/05, Rodrigo B. de Oliveira [EMAIL PROTECTED] wrote: ... I'm getting off-by-one errors only with raise/throw statements: The behavior is actually a little more complex but still predictable. The stack trace entry for the raise line is always the line of the next statement in the same method: The workaround was to emit debugging information again for a Nop just after the raise statement. Now the lines are reported correctly in both runtimes. -- bamboo http://blogs.codehaus.org/people/bamboo/ Got objects? http://www.db4o.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch for generating debug info in System.Reflection.Emit
On 7/28/05, Rodrigo B. de Oliveira [EMAIL PROTECTED] wrote: ... I'm getting off-by-one errors only with raise/throw statements: The behavior is actually a little more complex but still predictable. The stack trace entry for the raise line is always the line of the next statement in the same method: src name=other.boo def foo(): raise foo return 1 def bar(): foo() bar() /src I get then: Unhandled Exception: System.ApplicationException: foo in [0xa] (at Other.boo:5) OtherModule:foo () in [0x0] (at Other.boo:8) OtherModule:bar () in [0x0] (at Other.boo:10) OtherModule:Main (System.String[] argv) Any ideas? bamboo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] [PATCH] params attribute missing in System.Array.GetValue and System.Array.SetValue
Could someone pls review and commit the patch attached to the following bugzilla issue: http://bugzilla.ximian.com/show_bug.cgi?id=75516 Thanks! -- bamboo http://blogs.codehaus.org/people/bamboo/ Got objects? http://www.db4o.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] debugger module does not build
../frontend/Interpreter.cs(101) error CS0117: `Mono.Debugger.ThreadManager' does not contain a definition for `TargetOutputEvent' After a fresh checkout. Everything (mono/mcs/debugger) are uptodate (rev. 45194). Rodrigo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch for generating debug info in System.Reflection.Emit
Hi, I've just built the latest mono/mcs/debugger from the repository and although debugging information is being emitted now, the runtime and the debugger cannot make use of it. I get no source information on stack traces and mdb is unable to display source lines. The only important setting I've used on building mono was --with-preview=no. Here's a console dump of a session with mdb: [EMAIL PROTECTED]:~/dotnet/boo/build$ mdb booish.exe Mono Debugger (mdb) run Starting program: booish.exe ** Message: x86-linux-ptrace.c:77: b6d53bb0 - can't read target memory of 16935 at address b7ff7195 : Argumento inválido Process @4 stopped at #0: 0xb725b430 in BooishModule.Main(System.String[]). BooishModule.Main(System.String[]): 0xb725b430 push %ebp (mdb) n Process @4 stopped at #0: 0xb725b431 in BooishModule.Main(System.String[])+0x1. 0xb725b431 mov%esp,%ebp (mdb) I'm running ubuntu hoary and uname -a reports: Linux bambuntu 2.6.10-5-k7 #1 Fri May 20 15:49:12 UTC 2005 i686 GNU/Linux Any ideas? Rodrigo On 5/17/05, Lluis Sanchez [EMAIL PROTECTED] wrote: Hi! This patch adds some basic support for generating debug info in SRE. ... I'll commit if there are no objections. Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch for generating debug info in System.Reflection.Emit
is this already in? On 5/18/05, Ben Maurer [EMAIL PROTECTED] wrote: Miguel asked me to look at the memory impact of this patch. ... So, this is probably ok. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch for generating debug info in System.Reflection.Emit
On 5/17/05, Lluis Sanchez [EMAIL PROTECTED] wrote: Hi! This patch adds some basic support for generating debug info in SRE. It implements ModuleBuilder.DefineDocument and ILGenerator.MarkSequencePoint, and should be enough for most of compilers. With this patch, Boo and IKVM can generate correct debug info. WAHOO! :) Rodrigo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Embedding Mono in a Virtual World
You might be able to cook up something with serializable objects and lightweight threads based on generators (yield) But this is just food for though... On Fri, 18 Mar 2005 18:30:31 + (GMT), Jim Purbrick [EMAIL PROTECTED] wrote: Is it possible to save and load mono stacks? I'm currently looking at embeding mono in a virtual world application to run user scripts. I need to be able to save the state of a running script, send it to another machine and start the execution where it left off. Can it be done? If so how? Cheers, Jim. Send instant messages to your online friends http://uk.messenger.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- bamboo http://blogs.codehaus.org/people/bamboo/ Got objects? http://www.db4o.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Pascal Compiler Thoughts
Have you considered adopting boo[1] as the compiler infrastructure? I'd love to cooperate with you and make sure the boo compiler infrastructure can accommodate the needs of object pascal. [1] http://boo.codehaus.org/ On Mon, 14 Mar 2005 12:42:11 -0800, Grant Hess [EMAIL PROTECTED] wrote: I've attached a quick document with a (sort-of) proposal for the Object Pascal compiler. This is just notes from my quick brainstorming on the concept, nothing concrete. Just something to get the ball rolling on this idea. Read if you are interested. Comments back to the list, please. Thanks ... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
