[MonoDevelop] Moving to MSBuild

[Michael Hutchinson]

On Sat, May 17, 2008 at 1:54 PM, "Andrés G. Aragoneses"
<knocte at gmail.com> wrote:
...
>>>  I have a question about this: Will the MD file format be maintained
>>>  anyway (or not dropped at least)? If the answer is 'no', then I just
>>
>> At the very least, we will certainly have importers...
>
> How's the thing evolving? IMO this should be a combo box that lets you
> select the file format when creating a project/solution, like image
> manipulation programs do.

There's no reason to allow people to create new mds/mdp solutions and
projects, as it's essentially a deprecated format. If people really
need it for some strange reason, they can use the project exporter.
Eventually we will drop mds/mdp support.

...
>> We want VS compatibility where possible, so we will use .csproj and
>> .vbproj etc.,  but apart from that I see no reason to invent lots of
>> new file extensions.
>
> I wasn't advocating for inventing more extensions, but certainly was worried
> about this strategy that MS/MSBuild/VS selected, which I guess imposes how
> MD should behave in this matter (but what happens with project file formats
> which use a language that VS cannot open? for example, to mention the most
> uncommon, PHP.NET?).

We can easily add new formats. *MSBuild*'s strategy is to use .proj
for all projects.

Visual Studio's .csproj/vsproj I assume were for some kind of
backwards-compatibility (maybe it was just so the names looked
familiar to users!). Note also that .sln isn't actually an MSBuild
format either, it's legacy VS (though MSBuild and MD understand it).

Since VS2005+ uses MSBuild as its build engine, it will be able to
build any new MSBuild-format files we create, even if VS itself does
not understand them.

...
>> VS solutions aren't actually MSBuild files, even though MSBuild
>> understands them, and it would be possible to represent nested
>> solutions with MSBuild files, but VS would not be able to load them.
>
> Then it's not worth doing it, right? Because of interoperability reasons.

Correct. Well, we could support it, and allow VS to understand only a
subset of our solutions, but that would only confuse 95% of users IMO.

>> Solution folders (structuring of projects within a solution) partially
>> solve the problem. We will probably also have "workspaces" for
>> grouping solutions, but the solutions themselves will be VS solutions.
>
> That's it, they partially solve the problem and is my main concern about
> this project file format, which is why I though MD format should remain
> always as a fallback IMHO.

We will have "workspaces" that can contain multiple solutions. VS will
understand the solutions, but only MD will understand the workspaces.
However, the workspaces will still be MSBuild format, and hence
buildable on windows.

There are actually very few use cases where nested solutions are
needed, and I believe that those are solved *better* by the
workspaces.

Consider:
* A solution is an environment for resolving project references
* These projects are not intended to be developed or distributed
separately -- if this is not the case, they should be referenced as
pkgconfig libraries, not projects.
* Therefore, you only need *one* solution to contain all the projects
for your current solution.

Many of the "solutions" in the MonoDevelop solution tree, for
examples, are not "solutions" in any meaningful sense of the word, as
they depend on projects that are children of other solutions.

The main use case for workspaces is:
* Consider our "extras" directory
* Each solution is intended to be distributed separately from MD; it
builds against the *system* Monodevelop, i.e. references pkgconfig
monodevelop packages
* The only reason they are included within the MonoDevelop solution
tree is so that they can be built against the unstable/development
MonoDevelop
* In summary, workspaces are an environment for resolving pkgconfig references.

This use case doesn't work right now. Our solutions are arbitarily
nestable, with no thought to the actual consequences of doing so.
Nested solutions are going to die, even in the mds format.

...
>> We will be doing this for C projects etc. MSBuild files are about as
>> flexible as makefiles. We just need to write the relevant build
>> targets. VS seems to invoke the targets through MSBuild to do the
>> actual builds, making it similar to our makefile integration.
>>
>> VS C/C++ projects don't use the MSBuild format yet, but that is likely
>> to change in the future. TBH, we don't really care about unmanaged VS
>> projects ATM.
>
> But in this case, which extension will these type of projects use?

.proj

>>>  4) Use of not-win32ish stuff (for example \backslashes\ for paths).
>>
>> Unfortunately, this would mean the projects would not be be buildable
>> with MSBuild on Windows, let alone be able to be opened in VS.
>
> Yes, I'm not proposing to use normal slashes for MSBuild, just saying that
> MD format is good because of its not-win32ish way of expressing the paths
> (the future MD for Win32 won't have any problem building it if it's prepared
> for replacing them at execution time with the native counterpart...).

What advantage does that give? If MD assumes that paths in MSBuild
files are Win32 format, and converts them to/from the native format
when loading/saving, then it will work fine everywhere.

Think of the MSBuild files as makefiles. VS only supports a subset of
the features, but we do not have to let this limit us. The only real
argument you have made for keeping mds files is for nested solutions.
These can be expressed in MSBuild format (though nested solutions can
too), and hence although it's not VS-compatible, it will still be
buildable by MSBuild, AND VS will be able to open the child solutions.
Note that every argument I have made for VS applies to SharpDevelop
too.

Ultimately, we will replace the MD build engine with MSBuild. It's not
just going to be the format in which we load/save the projects, it'll
be much more fundmental than that.

-- 
Michael Hutchinson
http://mjhutchinson.com