Emacs (and other editors) integration -- projects

[Robin Neatherway]

Hi all,

I have the emacs integration back in a reasonable state. As before,
though, it only handles a single script file.

I thought I would solicit opinion on how projects should be handled.
VS and monodevelop both use a solution containing projects model. I
see two main options for the emacs integration:

1. Extend the F# intellisense backend to be able to load in a
.sln/.fsproj file created by VS/monodevelop. This would make the
simplest extension in terms of having a robust way of talking about
assembly dependencies etc, and would make it easy to collaborate with
people using the other editors. The backend could also offer ways to
modify the project file. This option would also allow for code to be
shared with the monodevelop binding.

2. Come up with a simple emacs project file structure, perhaps just a
.dir-locals file:

http://www.gnu.org/software/emacs/manual/html_node/emacs/Directory-Variables.html

This could contain a list of files, another list of assemblies that
this project depends on and compiler options etc. This option seems to
create fragmentation, although it might be easier to get started this
way.

Thoughts?

Cheers,
Robin

[Don Syme]

Hi Robin,

Having helped advise Tomas and Ben with regard to MonoDevelop, I'd recommend focusing on option 1. Supporting option 2 as well would not be a bad thing, but probably not worth the fragmentation, unless it is very easy to build, implement and document.

The .fsproj file format really is the "standard" format for F# (I suppose Makefiles are the other standard format) The Mono team have effectively embraced .csproj for C#, and I think for good reasons.

Choosing a new format may be optimal for one programmer, but the ability to contribute to existing F# projects with any editor you like (and using the same project metadata) is very good for shared F# projects and for spreading F# adoption. With that in place, the one (or more!) Emacs-lovers on a team can contribute to code on an equal basis, with good tooling support.

Further, by getting the infrastructure shared you set the standard for future support in other editors.

Kind regards
Don

________________________________________
From: fsharp-o...@googlegroups.com [fsharp-o...@googlegroups.com] on behalf of Robin Neatherway [robin.ne...@gmail.com]
Sent: 26 November 2012 19:22
To: fsharp-o...@googlegroups.com
Subject: Emacs (and other editors) integration -- projects

Hi all,

http://www.gnu.org/software/emacs/manual/html_node/emacs/Directory-Variables.html

Thoughts?

Cheers,
Robin

--
--
You received this message because you are subscribed to the Google
Groups "FSharp Open Source Community" group.
To post to this group, send email to fsharp-o...@googlegroups.com
To unsubscribe from this group, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource?hl=en

[Tomas Petricek]

Hi Robin, that sounds fantastic!

I think the option (1.) would be ideal. Being able to share fsproj files
between emacs and other editors is one thing. The other is that it could be
also used by other tools that operate on F# sources/projects. So, having
that in FSharp.CompilerBinding would be perfect (with some new commands in
fsautocomplete).

I'm not exactly sure how msbuild/xbuild work, but if they expose some API
that can be used to parse the msbuild file, then it should be doable
(without writing your own engine, which sounds like a lot of work).

There is also an F# make (FAKE) DSL (https://github.com/fsharp/FAKE) but I
think this is not usually used to build individual projects (but to run unit
tests, do deployment, packaging, etc.)

Tomas

[Don Syme]

Yes, I believe MSBuild and xbuild expose an API. Certainly MSBuild does - Visual Studio uses it. I'm not certain but I think that MonoDevelop does too.

Don

________________________________________
From: fsharp-o...@googlegroups.com [fsharp-o...@googlegroups.com] on behalf of Tomas Petricek [to...@tomasp.net]
Sent: 26 November 2012 21:23
To: fsharp-o...@googlegroups.com
Subject: RE: Emacs (and other editors) integration -- projects

Tomas

--

[Robin Neatherway]

Great, my preference is to stay compatible with Monodevelop/VS too.

I notice that my Mono installation includes:

Microsoft.Build.Engine.dll
Microsoft.Build.Framework.dll
Microsoft.Build.Tasks.v4.0.dll
Microsoft.Build.Utilities.v4.0.dll
Microsoft.Build.dll

Is this the xbuild implementation of MSBuild?

Does Monodevelop use this too?

I'll look back into the monodevelop fsharp binding and see what I can find.


Robin

[Tomas Petricek]

Yes, I think these are the xbuild assemblies to use.

I'm not sure the fsharpbinding for MonoDevelop uses them directly - I guess
they are more likely used by MonoDevelop directly (which then just calls F#
binding after it loads what it needs - the F# binding just gets a list of
files etc.) So you may need to check the MonoDevelop source code...

T.

[Andrew Cherry]

My elisp is probably not up to helping out much here, but another vote for giving emacs the ability to at least basically work with fsproj files. If that could be generalized to csproj files as well, that would be potentially enormous. Lack of interoperability with VS has always traditionally knocked signifcant emacs usage on the head in the .NET world IME. If you could get as far as something like a *proj minor-mode that would potentially open up a lot more opportunities for using emacs.

A.