[Mono-dev] Altering our build system.

[Rafael Teixeira]

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 <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).
> Thanks,
> Jonathan
>
> 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:
>>
>>        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 at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>