[Mono-dev] Ideas for Mono on Windows

[Atsushi Eno]

As one of the true maintainers of classlibs I'm completely against
ideas to drop cygwin support as it completely destroys my hacking life
(note that I don't mean I dislike adding VS build support), but anyways
here I agree with jpobst on the part to keep using dll.sources.

Here is what I do for adding new source files into svn:
- Update *.dll.sources file:
   ls ../../build/common/*.cs */*.cs | sort > System.Foo.Bar.dll.sources
   make
- Collect which files should be mentioned in ChangeLog:
   "svn diff FooBar.dll.sources"
   -> copy the rectangle(s) on the console output
- Add new files to svn (and svn propdel svn:executable):
   copypaste those lines in "svn add" command line.

Can these tasks ever easier by switching to your beautiful xml csproj?
In MWF land did we create csproj->sources converter?

Classlib hackers who uses Visual Studio: how do you do those tasks?

Atsushi Eno

Jonathan Pobst wrote:
> Hey Jonathan,
> 
> I'm glad to hear that you have the runtime building nicely on Windows. 
> In my spare time, I have been playing with making an MSBuild script for 
> the managed pieces, and was hoping you might have something similar for 
> the unmanaged part.  (Which I know nothing about.)
> 
> The route I took (and this is my first time playing with MSBuild) was to 
> write an McsTask that simply calls (g)mcs with the same command line as 
> the make system.  In this way, I simply use the existing .sources files. 
>   This may be an easier scenario to achieve than switching over to 
> .csproj files, as it allows people to continue doing things the way they 
> always have.
> 
> It would be nice to have all platforms build with xbuild, but if that's 
> not possible, at least the burden of maintaining two build systems this 
> way is a lot less than if we tried to maintain changes to .csproj files.
> 
> Jonathan
> 
> 
> Jonathan Chambers wrote:
>> Hello All,
>>       Mono on Windows has never been easy. However, lately things to 
>> have continually gotten worse (or I and others have just gotten more 
>> annoyed). Setting up an environment takes a lot of effort for a normal 
>> windows developer. Cygwin and the whole Makefile based process is very 
>> foreign for Windows developers. Not to mention the busted make in cygwin 
>> and cygwin issues on Vista (amd64). Most people have had enough interest 
>> in building mono on windows that they took the time to work things out 
>> (usually at least a day). But that's just the first time; try setting 
>> everything up again on a different machine or updating your cygwin and 
>> things start over.
>>
>> I see the basic issues as:
>>
>> 1) Cygwin development environment is less than ideal. It's foreign to 
>> most Windows developers and is a barrier to entry for most people.
>> 2) Debugging is mostly impossible. gdb seems to provide little help on 
>> Windows (echoed by others on #monodev)
>> 3) Compilation takes forever. I am working on a Dual Quad Core machine 
>> (8 cores) at 3.6 Ghz. The mono build process still takes hours on my 
>> machine. This may be aggravated by virus scanners or other similar 
>> software, but the fact remains that all Windows users run virus scanners.
>>
>>
>> As to not just be a complainer, I am offering some suggestions/ideas and 
>> hoping for others to do the same (or at least critique mine ;-)). Before 
>> I offer any suggestions, I think we need to balance between two things. 
>> One is making life easy for the mono build/package team to produce a 
>> Windows product. It's not real easy now, but we shouldn't make it any 
>> harder. The second thing is making life easy for those who wish to 
>> work/contribute to mono on Windows. This second item is tough at this point.
>>
>> 1) We should consider using MSVC as the default compiler for C code on 
>> Windows. I can compile the entire Visual Studio solution for the runtime 
>> in minutes. It takes 20-30 seconds if I do a parallel build. We can also 
>> use the Visual Studio debugger on Windows, which IMO is betten than gdb 
>> on Windows.
>>
>> 2) Two propositions for the class libraries have been mentioned 
>> previously. One is a lightweight, 'managed make' system that could be 
>> run easily on windows in place of all the build infrastructure provided 
>> by cgywin. This obviously allows us to keep using Makefiles on other 
>> platforms and keep a unified build process, but requires someone write 
>> the tool (and maintain it). Another option is to moved to MSBuild/xbuild 
>> for the class libraries. This would change the build process on all 
>> platforms, and require some fixing of our current xbuild tool. 
>> MSYS/MinGW has also been mentioned, but I don't consider that much 
>> better than Cygwin. I attempted to get it working one time, but gave up 
>> after a few days of hacking.
>>
>> Simply opening a csproj file for a class library, hacking on it, testing 
>> under .Net and mono, and then contributing the changes seems a like a 
>> good goal to aim for in regards to contributors. The build/packaging 
>> guys can respond with what they are looking for on Windows.
>>
>> Any thoughts/responses on making mono better on Windows is appreciated.
>>
>> Thanks,
>> Jonathan
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>