Just a cralification; I don't mean that your project is waste of time. I was just worried that mcs hackers might have to spend their time unnecessarrily. Sorry if it sounds like nasty intemptation.
Atsushi Eno
Please provide all what you should put to require mcs hackers to review the patches. It is not a good idea to put patches step by step, without obvious purpose. If it is being reverted later when the purpose turned out that we should not have in mcs codebase, it will be just waste of time.
If you are going to create another tool, then you should keep your changes on those mcs sources in your local mcs copy, so that other mcs hackers don't have to be bothered about whatever they never use.
Atsushi Eno
Gaurav Vaish wrote:
Ok, I think I understood what you are going to do.
Ahh! Finally, I make a breakthrough. ;-)
So what you need is, to have public members that are accessible from your own tool 'mcsdoc', which 1)references to mcs.exe as an assembly and 2)runs its Main() entrypoint and 3)get results that
Hmm.. I never thought of accessing it as an assembly. But yeah.. now I think that may be a good idea. Thanks buddy!
Otherwise, you must need more patches to get it working (to get documentation output). At least there should be patch for driver.cs that handles your documentation support.
Yes. I have code change for driver.cs also. Only that I never wanted to push it to driver.cs in "mcs" as it would use MCSDoc. If you look at driver.cs in the cvs, it has some changes.
-- Cheers, Gaurav http://csdoc.sf.net ---------------------- _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
_______________________________________________ Mono-hackers-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-hackers-list
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
