[Mono-dev] Altering our build system.
monoman at gmail.com
Fri May 21 08:17:16 EDT 2010
Does xbuild already convert solutions to a hidden .proj and run it, as
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
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... :)
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."
On Thu, May 20, 2010 at 3:37 PM, Jonathan Chambers <joncham at 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).
> On Thu, May 20, 2010 at 2:10 PM, Jonathan Pryor <jonpryor at 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:
>> 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 at lists.ximian.com
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list