Re: [Mono-dev] Altering our build system.
Does xbuild already convert solutions to a hidden .proj and run it, as msbuild does? If so, we just keep the solutions as master build files for each profile: for example: mono-core-profile-2.0.sln, mono-core-profile-4.0.sln, etc.. Which enables to build from either the IDE and the command line, exactly the same build. The Debug/Release targets would build just the managed libraries, specific FullDebug/FullRelease targets could be the ones that build also the runtime (including native code), and RuntimeDebug/RuntimeRelease targets would build just the runtime (bootstrap part). Monodevelop would need to support working with .sln files (VS2008 compatible ones, until VS2010 gets more deployments) to make it a fully all-devs-can-get-in proposition. i do have projects that need to mix building things that VS doesn't handle too well (like building sub-solutions with another VS version, and packaging and building libs with other tools/languages), for that cases I do have some fake .csproj, with the building instructions, I even developed some custom tasks to wrap some tools that msbuild doesn't support directly. I think that would be the case to have the builds of the runtime, native libs and corlibs, integrated. Also I do have lots of older projects that use a mix of NAnt (as the main build driver) and msbuild, that i'm slowly migrating to use only msbuild, as I need to touch them. Although NAnt has a more imperative way of doings, which looks more easily recognizable by most devs, i think that msbuild data-flow driven (kind of functional) design scales better to future parallelization of the build process. Just sharing my experience with mixed .NET/native projects in windowsland... Worth 2 cents as always... :) Fun, Rafael Monoman Teixeira --- To be creative means to be in love with life. You can be creative only if you love life enough that you want to enhance its beauty, you want to bring a little more music to it, a little more poetry to it, a little more dance to it. Osho On Thu, May 20, 2010 at 3:37 PM, Jonathan Chambers jonc...@gmail.com wrote: I've been looking at a MSBuild based build for the class libs (based upon Jonathan Pobst's MonkeyBuilder). To actually make the projects usable in visual studio, they need to be one of a list of well known project types. While MSBuild can handle an arbitrary .proj file with arbitrary MSBuild tasks, to build inside VS you would need to use a .csproj. Currently, I have a build basically working using a .proj file with custom MSBuild tasks that mirror what MonkeyBuilder does (which mirrors the auto* based build). csproj files could be used, but it raises a few questions: 1. Can we build using either .Net compilers or mono compilers? 2. Is there the concept of make and make install (building class libs versus installing them in some location)? 3. Running unit tests There are more issues, but this is already a bit unrelated to Miguel's original post. The Windows build has recently gone downhill, so hopefully any changes we make might make life better (and hopefully no worse). Thanks, Jonathan On Thu, May 20, 2010 at 2:10 PM, Jonathan Pryor jonpr...@vt.edu wrote: On Thu, 2010-05-20 at 12:52 -0400, Miguel de Icaza wrote: I would like to move to a setup where by default we assume we have a working mcs/runtime and we build the configured profiles (defaulting to 2.0 and 4.0). ... A final wish-list item would be to split up the *core* libraries from most of the extra libraries. The moonlight team is using a special process already to limit the number of assemblies built. This would dovetail nicely with the idea of splitting up mcs into smaller modules as part of the git migration; see: http://www.mono-project.com/GitMigration I would also suggest using xbuild to build the non-core libraries. This will make it easier for people who aren't using Unix to build the libraries, as Visual Studio could then (hopefully) be used for building, thus avoiding the pain that is Cygwin for everything except the runtime and core libraries. - Jon ___ 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 mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Android Support [1/4]
I'm also interested in this. I'm trying to run configure with options to make it use the android ndk tools etc. as described here: http://warpedtimes.wordpress.com/category/technology/android-technology/ It falls over when wanting to compile test code, so I'm setting various options to get it to go a little further, but it is painful ... any help would be very much appreciated (such as the magic ./configure comand line). Thanks, Damian JeroMiya wrote: Oops, meant to send this to the list. Just a quick question. I'm new to the mono build process - with these changes, how do you target the android platform when building mono/mcs? ... -- View this message in context: http://mono.1490590.n4.nabble.com/PATCH-Android-Support-1-4-tp2016287p2226260.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SGen improved and looking for testers
Hi Mark, I did some tests with May 19th tarballs and I'm impressed to see that the memory usage in one of my test is a lot lower when using sgen compared to boehm. Stability also seemed to be great until I got a segmentation fault. Here's the call stack in case you can get something out of it: #0 0x081c2d12 in copy_object_no_checks (obj=0xf780fd98) at sgen-gc.c:2082 #1 0x081c3a84 in major_copy_or_mark_object (obj_slot=0xf189c348) at sgen-major-copying.c:384 #2 0x081c4180 in major_scan_object (start=value optimized out) at sgen-scan-object.h:81 #3 0x081c595d in major_collection (reason=0x82b3b2d minor overflow) at sgen-gc.c:2335 #4 0x081c666a in minor_collect_or_expand_inner (size=4096) at sgen-gc.c:3602 #5 0x081c68c5 in mono_gc_alloc_obj_nolock (vtable=0x8383cf0, size=value optimized out) at sgen-gc.c:4148 #6 0x081c6b0c in mono_gc_alloc_vector (vtable=0x8383cf0, size=32, max_length=4) at sgen-gc.c:4272 #7 0xf79df5ab in ?? () #8 0x08383cf0 in ?? () #9 0x0020 in ?? () #10 0x0004 in ?? () #11 0x082d869c in nursery_size () #12 0xf2935928 in ?? () #13 0x088360b0 in ?? () #14 0xf2935958 in ?? () #15 0x081c0103 in register_for_finalization (obj=0xf78016b8, user_data=0xf7801718, generation=value optimized out) at sgen-gc.c:4901 #16 0xf79dca25 in ?? () #17 0x08383cf0 in ?? () #18 0x0020 in ?? () #19 0x0004 in ?? () #20 0x08140f50 in object_register_finalizer (obj=0xf78016b8, callback=0xf2935948) at gc.c:302 #21 0xf55ccb40 in ?? () #22 0x08383cf0 in ?? () #23 0x0004 in ?? () #24 0x in ?? () The process that crashed is multi-threaded and is doing heavy allocations/deallocations. It's loading data from a database and doing calculations. Jonathan -Message d'origine- De : mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] De la part de Mark Probst Envoyé : Monday, December 14, 2009 12:03 PM À : mono-devel-list Objet : [Mono-dev] SGen improved and looking for testers Hello everybody, SGen, our new garbage collector, has improved quite a bit since my last plea for testers about a month ago, so here I go again... We've improved stability, performance, and, most importantly, memory consumption, to the point where SGen now uses less memory than Boehm for the (not too complex) workloads we're testing it with. Performance isn't there yet, and it's still not as stable as Boehm, but I'd like to ask developers who want to help us to give it a try and to give us feedback and bug reports. I'm especially interested in cases where it crashes and in cases where it uses (significantly) more memory than Boehm. It's still only available for Linux on AMD64 and x86. To enable it, configure mono with --with-gc=sgen --enable-minimal=aot and, if you have a line starting with ENABLE_AOT in mcs/build/config.make, comment it out or delete it. Thanks! Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.716 / Virus Database: 270.14.100/2554 - Release Date: 12/14/09 02:37:00 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SGen improved and looking for testers
Hi Jonathan, I did some tests with May 19th tarballs and I'm impressed to see that the memory usage in one of my test is a lot lower when using sgen compared to boehm. That's good to hear! We're getting similar reports from the Plastic SCM folks. Stability also seemed to be great until I got a segmentation fault. Here's the call stack in case you can get something out of it: #0 0x081c2d12 in copy_object_no_checks (obj=0xf780fd98) at sgen-gc.c:2082 There's not too much I can make of this, unfortunately. Does your application use non-root appdomains? Can I reproduce this myself somehow? If not, would you be willing to spend some time helping me figure out this bug? Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
