On Wednesday, 18 September 2013 at 07:13:01 UTC, Manu wrote:
> That looks thoroughly unofficial. Why should I trust it?

You shouldn't unless you are going to verify source and build package on your own ;) AFAIK there is no official MonoDevelop 4 package for Debian-based distros and one won't appear in any time soon. Alex provides latest suitable MonoDevelop as blob via http://simendsjo.me/files/abothe (with generous help of simendsjo for hosting)

I personally can only recommend to use proper bleeding edge Linux distributive in that regard :P

P.S. It is a disaster how much trouble MonoDevelop upstream is causing for Mono-D judging by Alex posts. Breaking plugin API in minor releases all the time.

On Wednesday, 18 September 2013 at 12:37:28 UTC, Dicebot wrote:
> On Wednesday, 18 September 2013 at 07:13:01 UTC, Manu wrote:
>> That looks thoroughly unofficial. Why should I trust it?
>
> You shouldn't unless you are going to verify source and build package on your own ;) AFAIK there is no official MonoDevelop 4 package for Debian-based distros and one won't appear in any time soon. Alex provides latest suitable MonoDevelop as blob via http://simendsjo.me/files/abothe (with generous help of simendsjo for hosting)
>
> I personally can only recommend to use proper bleeding edge Linux distributive in that regard :P
>
> P.S. It is a disaster how much trouble MonoDevelop upstream is causing for Mono-D judging by Alex posts. Breaking plugin API in minor releases all the time.

Well, Miguel is no longer interested in Linux I guess.

On 18 September 2013 22:37, Dicebot <public@dicebot.lv> wrote:

> On Wednesday, 18 September 2013 at 07:13:01 UTC, Manu wrote:
>
>> That looks thoroughly unofficial. Why should I trust it?
>>
>
> You shouldn't unless you are going to verify source and build package on
> your own ;) AFAIK there is no official MonoDevelop 4 package for
> Debian-based distros and one won't appear in any time soon. Alex provides
> latest suitable MonoDevelop as blob via http://simendsjo.me/files/**abothe<http://simendsjo.me/files/abothe>(with generous help of simendsjo for hosting)
>
> I personally can only recommend to use proper bleeding edge Linux distributive in that regard :P
>
> P.S. It is a disaster how much trouble MonoDevelop upstream is causing for Mono-D judging by Alex posts. Breaking plugin API in minor releases all the time.
>

So... is MonoDevelop effectively a one-man project? How is it that it doesn't have a Debian distribution? It's the most popular form of linux by far.

On 18/09/13 14:37, Dicebot wrote:
> You shouldn't unless you are going to verify source and build package on your
> own ;) AFAIK there is no official MonoDevelop 4 package for Debian-based distros
> and one won't appear in any time soon. Alex provides latest suitable MonoDevelop
> as blob via http://simendsjo.me/files/abothe (with generous help of simendsjo
> for hosting)

MonoDevelop 4 is in the "proposed" repository of Ubuntu 13.10:
https://launchpad.net/ubuntu/saucy/+source/monodevelop

... which I hope means that it will make it into the regular repositories of the final release next month.  It's also in Debian Unstable:
http://packages.debian.org/sid/monodevelop

On Wednesday, 18 September 2013 at 12:44:07 UTC, Manu wrote:
> So... is MonoDevelop effectively a one-man project?

https://github.com/mono/monodevelop/graphs/contributors ;)

> How is it that it
> doesn't have a Debian distribution? It's the most popular form of linux by
> far.

There is package for older version. Version 4 branch is rather new and it will take some time until maintainer of non-bleeding edge Linux distributions will consider it stable enough to be allowed into official repositories.

It is a common approach on its own. Problem is the plugin API incompatibility they do which does not allow Alex to maintain Mono-D for older version without effectively spending twice more time/efforts. I don't know the details but he was ranting about it quite a lot :)

There is a certain unpleasant similarity between MonoDevelop and DMD development process :D

On Wednesday, 18 September 2013 at 12:47:43 UTC, Joseph Rushton
Wakeling wrote:
> MonoDevelop 4 is in the "proposed" repository of Ubuntu 13.10:
> https://launchpad.net/ubuntu/saucy/+source/monodevelop
>
> ... which I hope means that it will make it into the regular repositories of the final release next month.  It's also in Debian Unstable:
> http://packages.debian.org/sid/monodevelop

Most frustrating thing here is that that `proposed` repo has
4.0.5 while Mono-D will only work on 4.1.7+ (judging by
http://mono-d.alexanderbothe.com/) :)

On Wednesday, 18 September 2013 at 12:55:14 UTC, Dicebot wrote:
> On Wednesday, 18 September 2013 at 12:47:43 UTC, Joseph Rushton
> Wakeling wrote:
>> MonoDevelop 4 is in the "proposed" repository of Ubuntu 13.10:
>> https://launchpad.net/ubuntu/saucy/+source/monodevelop
>>
>> ... which I hope means that it will make it into the regular repositories of the final release next month.  It's also in Debian Unstable:
>> http://packages.debian.org/sid/monodevelop
>
> Most frustrating thing here is that that `proposed` repo has
> 4.0.5 while Mono-D will only work on 4.1.7+ (judging by
> http://mono-d.alexanderbothe.com/) :)

P.S.

I guess that makes Arch Linux 4.0.12 package unusable too. Love
that versioning hell.

On 18/09/13 14:56, Dicebot wrote:
> On Wednesday, 18 September 2013 at 12:55:14 UTC, Dicebot wrote:
>> Most frustrating thing here is that that `proposed` repo has
>> 4.0.5 while Mono-D will only work on 4.1.7+ (judging by
>> http://mono-d.alexanderbothe.com/) :)
>
> P.S.
>
> I guess that makes Arch Linux 4.0.12 package unusable too. Love
> that versioning hell.

That's annoying.  A minor version number bump shouldn't render plugins etc. incompatible.  It doesn't say many good things about the development process of MonoDevelop ... :-(

On Wednesday, 18 September 2013 at 11:45:55 UTC, Manu wrote:
?
> The problem I've always had with make-based build systems is rebuild
> dependencies... how do any of those build systems go performing a minimal rebuild,

As in "only rebuild the files that changed"?  In my experience, that comes with using make.  Even really ancient versions.

> or incremental linking?

This is a bit harder.  If you're using the Gold linker, -Wl,--incremental sounds like your medicine, though I'm not sure if Gold is ready for primetime, yet.

-Wyatt

On 18/09/13 15:54, Wyatt wrote:
> As in "only rebuild the files that changed"?  In my experience, that comes with
> using make.  Even really ancient versions.

More like, top-down vs. bottom-up resolution of dependencies.  E.g. suppose you've built GDC from source -- this means you've built both the GCC backend (and C/C++ compilers etc.) and the D frontend.

Now you pull in the latest updates to the frontend, and you want to rebuild. Theoretically, you shouldn't need to care about the backend at all -- it's already built -- and all that you should need to do is rebuild the frontend and the resulting GDC executable and libraries.

In practice, the GCC make process will trawl through all the different subdirectories related to the backend -- it'll find that nothing needs to be rebuilt, but it takes quite some time to check all of that, when you'd like your built system to be smart enough to avoid that kind of bottom-up checking.