Don't always assume the latest MonoDevelop (build and release multiple versions of binding instead)

[fsharp]

Don't always assume the latest MonoDevelop (build and release multiple versions of binding instead)

[funnelweb]

This work has been submitted in b2fafe2

[tpetricek]

Can this change be included in the alternative Makefile that does not use xbuild? (I think just duplicating the code is fine, because we still want to get rid of the no-xbuild version eventually, but I think it is important to make it available for systems that do not have Mono 3 yet - ideally until there is stable version of Mono 3, but at least until there is a binary beta version for more than just Mac...)

Also, you're using a hard coded path for MonoDevelop on Windows (c:\Program Files (x86)\MonoDevelop), which is not going to work if you install it elsewhere or if you have x86 version. Can you change this to check that the files are there and, if not, ask the user in the config script? (I almost never use standard installation directories to avoid mess and I'm sure other people may have different directories - i.e. if you build MonoDevelop.)

[funnelweb]

There are three roles: Users, Contributors and Releasers

users: the binding can be used on Mono 2.10.9 ok from the gallery ok on all platforms, no problems there

devs on windows: Am not sure what to do to configure on windows. The configure.sh script requires sh/bash so doesn't run on Windows anyway (we surely don't want build dependencies on Cygwin etc.). I think if people are going to develop this stuff with non-standard lcoations they can just work it out or push a request for a change. The project files already go through an "upgrade" when you open them in VS2012. And you also have to adjust for the project file version of MonoDevelop being used.

devs on mac/linux with xbuild: ok here

devs on Mac/Linux without xbuild: I'll take a look if the changes impacted this

releasers: today we only push-to-gallery from Mac/Linux using components built with F# 3.0, Mono 3.0 and xbuild. The actual components pushed can be used with F# 2.0, Mono 2.10.9 etc.

[tpetricek]

users

The users should be also able to get the bindings and build them - this is expected from an open source project and it is important for eventually merging this with standard repositories and distributions.

devs on windows

Not sure about others, but I'm happy with a cygwin dependence. It is the easiest way to get git & other tools to work anyway. But I agree we do not need to be able to build all packages on Windows (although I guess you need to build windows package to install it).

In general, I just think it would be good to keep this as inclusive as possible. We could just make everything work on Mac with latest Mono, but then it's not really fully cross-platform...

(But that is for a separate discussion, if you can add this to no-xbuild then I think that's perfect.)

[funnelweb]

@tpetricek - I know you had trouble moving your dev system to F# 3.0 and Mono 3.0. i guess that's still a problem or you wouldn't have done all the no-xbuild thinngs.

requiring developers/contributors to have F# 3.0/Mono 3.0 seems pretty reasonable in the big scheme of things... It sort of feels like time to push on and add ASP.NET, MonoGame and MonoMac support, and maintaing both build systems will be painful - experimenting with ASP.NET support was one reason why it got removed..... And the need for others to build from source is much reduced if we broaden the reach of the gallery-based bindings to include downstream MonoDevelops....

What do you think? Is it possible for you to move to F# 3.0 and Mono 3.0.. Moving to Mono 3.0 is worth it just for stable SGEN alone.

[7sharp9]

Windows is a tricky one as you have vs2012 express with F#. I'm not sure you would always have Cygwin. GitHub for windows is quite popular now.

On 7 Nov 2012, at 16:27, Tomas Petricek [email protected] wrote:

users

The users should be also able to get the bindings and build them - this is expected from an open source project and it is important for eventually merging this with standard repositories and distributions.

devs on windows

Not sure about others, but I'm happy with a cygwin dependence. It is the easiest way to get git & other tools to work anyway. But I agree we do not need to be able to build all packages on Windows (although I guess you need to build windows package to install it).

In general, I just think it would be good to keep this as inclusive as possible. We could just make everything work on Mac with latest Mono, but then it's not really fully cross-platform...

(But that is for a separate discussion, if you can add this to no-xbuild then I think that's perfect.)

—
Reply to this email directly or view it on GitHub.

[7sharp9]

I am just adding support to monogame for F# by the way. The initial pull request has been accepted and I'm working on a blog post about it.

On 7 Nov 2012, at 16:32, Ben Winkel [email protected] wrote:

@tpetricek - I know you had trouble moving your dev system to F# 3.0 and Mono 3.0. i guess that's still a problem or you wouldn't have done all the no-xbuild thinngs.

requiring developers/contributors to have F# 3.0/Mono 3.0 seems pretty reasonable in the big scheme of things... It sort of feels like time to push on and add ASP.NET, MonoGame and MonoMac support, and maintaing both build systems will be painful - experimenting with ASP.NET support was one reason why it got removed..... And the need for others to build from source is much reduced if we broaden the reach of the gallery-based bindings to include downstream MonoDevelops....

What do you think? Is it possible for you to move to F# 3.0 and Mono 3.0.. Moving to Mono 3.0 is worth it just for stable SGEN alone.

—
Reply to this email directly or view it on GitHub.

[funnelweb]

don't mind having a parallel build system for a while but we should drop it at some point. will patch it up for *nix.

we can't require Cygwin, that's not an inclusive option. few VS devs who might be interested in contributing will want to use that (or even know how to use it).

[funnelweb]

@7sharp9 kool. can you send a link to the pull request?

[tpetricek]

@funnelweb I think you're the main contributor to the project now, so I think it is fair to trust your judgement (especially if it will make your contributions easier) and just require Mono 3.0 as you say.

I did not install it just because I didn't want to spend too much time trying to build it on Linux. I guess I can contribute from Windows too (until installing Mono 3.0 gets easier or until someone buys me a Mac :-)), although it might be a bit tricky to do changes in the project files, because MonoDevelop is quite sensitive to that.

[funnelweb]

Looking at the makefile.no-xbuild I can see it is nice and simple for people doing emacs, vim binding development. we need to hide all the monodevelop stuff from them. is that what you're thinking?

monodevelop stuff is much harder and requiring F# 3.0 and Mono 3.0 to contribute to that that seems ok

how about

• Makefile -- dead simple makefile with no configuration for emacs, vim, FSharp.CompilerBinding.dll and FSharp.AutoComplete.dll
• configure-monodevelop.sh -- today's configure.sh
• Makefile.monodevelop -- produced by configure-monodevelop.sh, today's Makefile

Other editing systems with complex dependencies could have

• configure eclipse.sh
• Makefile.eclipse

Keep it simple for contributing to emacs, vim, autocomplete etc.

[7sharp9]

Ill get something over later. I'm travelling back home from London at the moment. I should have it blogged too in a day or so.

On 7 Nov 2012, at 16:45, Ben Winkel [email protected] wrote:

@7sharp9 kool. can you send a link to the pull request?

—
Reply to this email directly or view it on GitHub.

[funnelweb]

ok, this checkin 7dbb94d reorgs so the top level directory structure looks like this:

FSharp.AutoComplete
FSharp.CompilerBinding
FSharp.FSharpBinding.sln
Makefile.orig
configure.sh
README.md
emacs
monodevelop

The top level configure.sh and makefile are really simple and build the basic components. Everything to do with MonoDevelop is now under monodevelop. F# 3.0 is required for working in there, but not at the top.

I think this is the best balance and it avoids having two build systems for the complex monodevelop stuff. There's lots of room for contributors who are stuck on F# 2.0 and Mono 2.10.9 in the emacs/vim/eclipse/... areas :-)

tomas, is this ok?

-- ben

[tpetricek]

@funnelweb That sounds like a great solution, thanks!

[funnelweb]

great. done here: 7dbb94d