[MonoDevelop] Core / Extras and building

John Luke john.luke@gmail.com
Wed, 23 Feb 2005 22:47:39 -0500


On Wed, 2005-02-23 at 19:00 -0800, Todd Berman wrote:
>On Wed, 2005-02-23 at 17:30 -0500, John Luke wrote:
>>Hey all,
>>	I was mucking in the makefiles today to make it easier to run
>>MonoDevelop with mono -debug (and have it work) and I noticed something.
>>We have a rather curious Core/Extras split.
>>
>
>The Core and Extras split never was really finished. I had to spend too
>much time tuning building stuff in other places.
>
>>Here are my thoughts of what should be moved to Extras:
>>- language bindings for external languages (Java and Nemerle probably)
>
>Absolutely.
>
>>- things that are not stable enough to be in Core (we'll make an
>>exception for the debugger)
>
>The debugger should move.
>
>>- anything with odd dependencies
>>
>>I actually think MonoDeveloperExtensions can probably move from Extras
>>to Core.
>
>Not sure, read below.
>
>>
>>Last I don't think Extras should be included in the normal auto* build,
>>as it makes distcheck harder, etc. They should either each have their
>>own build methods, or one top-level auto setup for Extras.
>>
>>
>
>I disagree. Here is my opinion on that. Everything in Extras/ should
>either a) be conditionally built based on various package availability,
>and/or b) be --enable-this-plugin switched on/off. Having a single
>unified build system is far better in general, and makes it easier to
>build tarballs/etc. The only things (IMO) in Core/ should be stuff that
>either a) MonoDevelop *requires* or b) MonoDevelop users basically
>require (for an example, the C# binding is not 'required' by
>monodevelop, however, most of our users would like to see it built and
>installed by default).
>
>Any thoughts?
>

So I think we essentially agree and the auto* stuff is a trivial
difference in preference so it can stay as is. I'll probably move the
JavaBinding to extras soon and we can go from there.

I do think the Debugger should stay in Core because it is just too
important in the long run.