Since
- 1 won't be determined without the actually altered build system,
- 2 is just impossible (no make install alternative and we need it), and
- 3 in VS requires non-express versions as long as it depends on NUnit addin
(and of course we can't migrate our tons of existing NUnit tests to
Hello,
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
Hello,
1. Can we build using either .Net compilers or mono compilers?
I think that in this move to just build for the regular user, I do not
mind if we use either one.
2. Is there the concept of make and make install (building class libs
versus installing them in some location)?
It exists
On 5/20/2010 2:37 PM, Jonathan Chambers 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
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,
Hello guys,
Today's Mono build is designed very much with a bootstrapping focus
in mind: it does a full compiler bootstrap, library bootstrap and then
proceeds to compile the 2.0, 4.0 profiles and optionally the 2.1
profile.
This is problematic for people that are not hacking on
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
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
