I just realized it might not have been 100% clear what I think we should do.
We would in this case replace the references to our mono/mcs/class/XX/*/*cs source files, with the "../../external/referencesource/..." files, and then alter the original referencesource file with the #if statements. We have done that already in a couple of places. (More to come, last night we got XML working, but needs some work) On Sat, Nov 29, 2014 at 11:21 AM, Miguel de Icaza <mig...@xamarin.com> wrote: > Thanks Alex. > > I do not think that we will have a strict rule for when to copy and when > to reference. > > There are scenarios where we will want to keep a lot of the code in one of > our files, and pull code from the referencesource. At that point, we will > have to determine whether the use of #ifdefs or partial classes is a better > long-term maintenance approach than copying the source. > > In this particular case, I feel that we can modify the reference source, > and add the #if MONO around it. > > The reason is that the changes are pretty straight forward, it is mostly > about disabling code, and not about picking some specific bits of code and > putting them on our tree. So an #if would be nice, since we can do a few > things (a) we can later find out what code is being disabled by the port > (looking at work we can do in the future to import new versions, or > contribute back to .NET) and (b) the changes are minimal right now. > > Miguel > > On Sat, Nov 29, 2014 at 10:59 AM, Alexander Köplinger < > alex.koeplin...@outlook.com> wrote: > >> Here's the diff between my trimmed version and the original: >> http://www.mergely.com/9E70e5Ls/ >> >> Hmm, I actually think that most of the removed methods don't matter (as >> they aren't called anyway). I just wanted to make the file only contain the >> code that is necessary. >> The only "real" changes I had to make where accesses to internal fields >> in NumberFormatInfo, I just replaced them with accesses to the public >> properties that read them. >> >> Maybe it makes more sense to correct those accesses directly in the >> referencesource, so we can reference it from there? >> As a general guidance, when should we copy something to the Mono tree vs. >> editing referencesource? And if we copy, should we keep unneeded methods or >> remove them? >> >> -- Alex >> >> ------------------------------ >> From: mig...@xamarin.com >> Date: Sat, 29 Nov 2014 10:40:10 -0500 >> Subject: Re: [Mono-dev] Porting System.Numerics from referencesource, >> approaches for copying code? >> To: alex.koeplin...@outlook.com >> CC: mono-devel-list@lists.ximian.com >> >> >> Hey Alex, >> >> In general, the approach works. >> >> I am curious as to what is that you had to remove, and why. Can you >> describe the needed changes? (I saw the diff, but it is hard to tell what >> happened with it). >> >> I thought that Numerics was pretty much standalone. >> >> On Sat, Nov 29, 2014 at 10:32 AM, Alexander Köplinger < >> alex.koeplin...@outlook.com> wrote: >> >> Hey, I've been trying to port System.Numerics (BigInteger, Complex >> classes) from referencesource to see and feel what the process looks like. >> It mostly went fine, but there was one file (number.cs) I couldn't >> reference directly from the submodule and had to copy to the assembly folder >> in the Mono tree. >> >> I had to remove a bunch of code from that file to trim it down to only >> what is needed for System.Numerics to compile (all the tests pass now as >> well). >> Question: is this a valid approach or is there something better? Note >> that ifdefing the file wasn't feasible as it originally sits inside corlib >> and has many other unrelated methods in it. >> >> Here's the commit with the WIP: >> https://github.com/akoeplinger/mono/commit/d7c461155a975a35f76b79ebcc3fe33407bd5dce >> >> -- Alex >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> >> >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list