[Mono-dev] Ideas for Mono on Windows
Atsushi Eno
atsushi at ximian.com
Wed Nov 12 00:36:35 EST 2008
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
>
More information about the Mono-devel-list
mailing list