[Mono-dev] List of cleanup candidates for Mono 4.0

[Atsushi Eno]

Hello,

On 2014年11月28日 02:19, Alexander Köplinger wrote:
>
> Hey,
>
>         * gmcs/dmcs -> they just redirect to mcs now and without the
>         2.0 etc profiles it doesn't make sense to still have them
>
>
>     I like to keep them, to avoid breaking third party build scripts.
>
> Good point, however aren't they gonna break anyway when they rely on 
> 2.0 SDK which is no longer there anymore? Maybe now is the time 
> to make people aware they should update the scripts :)
>
>         * aspnetwebstack (i.e. MVC+WebApi) -> same reasons as for EF,
>         open-source and on NuGet, should be used from there
>
>
>     I am actually not sure about this one, is that really the case?
>
> The latest XamarinStudio/MonoDevelop MVC template installs it from 
> NuGet, so I think it should be fine to remove. It might not work 
> perfectly until the System.Web from referencesource is integrated, but 
> the same applies to the existing (outdated) copy we ship currently.
>
>         * Rx -> I'm not really familiar with this one, but I think
>         it's also on NuGet+open source
>
>
>     This one I know contains patches that make it work on Mono.  
>     Without these, they wont work. So this might have to wait.
>
> Interesting. I had a look at the NuGet package and it ships a 
> portable-net45 version, I always thought this was compatible with 
> Mono? If not, we could maybe look at upstreaming the patches.

Basically I agree that we could remove Rx. Yet some works need to be done.

Rx imports can be taken in two different parts: desktop and mobile.

For desktop, there is no difference (or almost no difference) in the 
sources.
There could be some not-implemented paths in the dependencies, but IIRC
I didn't #ifdef-ed out anything for that.

For mobiles there are many changes to build and run.

- Rx solution/project structure is quite complicated (most likely manually
   edited) to share several "MSBuild targets" fragments, as well as using
   some features that we don't (or maybe "didn't") support. So we generate
   different project files for mobiles, from within mcs/class.

   (The same xbuild problem applies to desktop, but within mono we
   build from dll.sources and our own Makefiles just like other assemblies.
   And for NuGet packages we wouldn't worry about that anyways.)

- We use NUnit for tests. Fortunately Rx tests use MSTest which were
   mostly compatible with NUnit syntax, we reuse that. Yet we needed
   several changes to the sources (e.g. "using NUnit.Framework;").
   - And the changes are not "committed" but rather "patched" at build
     time (mcs/class/* has some C# script for that).

- To make it build, we had to disable some parts by adding #if-s for iOS
   and Android, which are only for Xamarin.
   - I'm actually quite unsure how much of the existing Observables work
     fine on iOS (due to AOT limitation).
     For Android it worked almost perfectly.

The resulting diffs were already too much at that state, so I didn't send
them back to the original project. (For example, new tests could easily
miss "#if MONO use NUnit.Framework;" and it won't just build.)

Some changes would make sense to send back. IIRC there were some code 
paths that depend on WinRT or WPF that always exist on MS platforms but 
not on mono, and I #ifdef-ed out.

All those changes are in rx-oss-v2.2 branch in mono/rx so that anyone 
can review.

Anyways, basically we need patched version for mobiles. And some of
those reside in mono tree, so before nuking them out they have to be
rewritten to become independent of mono tree.

Atsushi Eno


> -- Alex
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list