[Mono-dev] xbuild usability

[Rafael Teixeira]

I have a related problem.

In trying to substitute NAnt on a large project with MSBuild, I needed
to create a top level solution with a single fake .csproj (to have
some support to change it from inside de VS.NET 2005 IDE, which
doesn't know to do anything with a .proj file), that calls MSBuild
recursively in the hundred solution files in the project, and then
executes some other tasks in the packaging targets for the whole
beast.

Looking at that scenario, I would propose a bit like the reverse of 2b:

xbuild would look first for a targets.proj file (or perhaps a .targets
file) that would have all helper targets and a default one that would
just build the solution file. then if not found it would look after
the solution file and the other .*proj files as normal.

The downside is compatibility, which means that in Windows using
MSbuild one would need to write the targets.proj filename in the
command line when needing to build the special targets. Nevertheless
all 2* solutions would not be compatible with MSBuild, as already
noted.

The advantage is that you can kind of attend your need and mine with a
single solution as it would be up to the targets.proj/.targets file if
just a single solution or dozens of them would be built by default.
That would make possible to avoid top level makefiles or at least to
shallow that into simple "relay-to-xbuild" targets

Just my two cents,

Rafael "Monoman" Teixeira
---------------------------------------
"To be creative means to be in love with life. You can be creative
only if you love life enough that you want to enhance its beauty, you
want to bring a little more music to it, a little more poetry to it, a
little more dance to it."
Osho



On Tue, Nov 3, 2009 at 5:04 PM, Jonathan Pryor <jonpryor at vt.edu> wrote:
> I'm toying with migrating Mono.Rocks to rely exclusively on MSBuild
> (it's the future!  plus it simplifies life for VS users).  This looks
> like it'll largely be trivial, but that's not the point of this email.
> This is just context.
>
> The point is improving the usability of xbuild so that it approaches the
> usability of make(1).
>
> So, usability point number one is already taken care of.  What's the
> most common thing to do with make?  Invoking the default target:
>
>        $ make
>
> Fortunately, xbuild also does this:
>
>        $ xbuild
>
> ...unless you have more than one .sln and/or .csproj in a directory.
>
>        rocks$ ls
>        Mono.Rocks.csproj  Mono.Rocks.sln ...
>
> Oops.  So already my usability with Mono.Rocks is hampered:
>
>        rocks$ xbuild
>        MSBUILD: error MSBUILD0005: Please specify the project or
>        solution file to build, as more than one solution or project
>        file was found in the current directory
>
> Proposal Number 1: .sln files should have higher precedence over
> other .*proj files, so if there is only one .sln file in a directory and
> also one or more .csproj files, an "unqualified" xbuild command will
> build the .sln file.
>
> Otherwise I'd need to do:
>
>        rocks$ xbuild Mono.Rocks.csproj
>
> I'm lazy; I don't want to type that much if I can avoid it. :-)
>
> Bonus: this is what MSBuild does as well -- 'msbuild' will runs
> Mono.Rocks.sln and ignores Mono.Rocks.csproj.  So implementing Proposal
> 1 improves MSBuild compatibility.  Yay.
>
> However, this raises us to the next "problem."  Makefiles make it easy
> to provide one-off "helper" targets:
>
>        # Makefile
>        shell:
>                csharp -r:lib/mono-rocks/Mono.Rocks.dll
>
>        check:
>                nunit-console2 $(mrdir)/Mono.Rocks.Tests.dll
>        # ...
>
> These logically belong to the solution as a whole, and should be
> executable from the topdir:
>
>        rocks$ xbuild /t:shell
>        rocks$ xbuild /t:check
>
> The question then becomes, how do we support this?
>
> If we follow the advice of Proposal # 1, the .sln will be executed,
> but .sln files don't support inserting <Target/>s.  We could place the
> <Target/>'s into a .csproj, but then we can't invoke the targets without
> also specifying the .csproj file (and since I'm lazy, I don't want to do
> that).
>
> There are several possible solutions here:
>
> Proposal 2a: Just use make(1)!
>
> Given that I'm attempting to stay within the confines of xbuild, this is
> a non-answer, but it may be the most workable answer regardless.
>
> Proposal 2b: Add support to xbuild to look for a .targets file which
> will be loaded inserted into the generated .proj file.  This .targets
> file would share the same basename as the .sln.  Thus rocks could have
> solution-level targets by adding a Mono.Rocks.targets file.
>
> Proposal 2c: Like 2b, except it looks for a .proj file instead of
> a .targets file.
>
> Proposal 2d: We could add a custom section to the .sln file file which
> explicitly references the .targets file, e.g. a
> CustomTargetsFile=foo.targets section.
>
> Proposal 2e: We add the <Target/> to an existing .csproj which is
> referenced by the .sln, and if the target specified on the command line
> isn't found within the .sln then xbuild looks within all .csproj files
> referenced by the .sln and executes the first matching <Target/>.
>
> The problem with all of these is that they amount to an extension of
> MSBuild.  I don't particularly care, though, as it would simplify
> command-line usage, and (as we all know) VS users don't use the command
> line, so these extensions wouldn't matter (as much). :-)
>
> That said, it is worth considering Microsoft's stance.  Some Googling
> time shows that the lack of "proper" solution support is biting *lots*
> of people, to the extent that dropping .sln file and moving entirely
> to .proj files within VS was the 3rd most requested feature for MSBuild:
>
>        http://blogs.msdn.com/msbuild/archive/2007/11/30/response-to-the-feature-poll.aspx
>
> .proj files, being "proper" MSBuild files, would allow adding <Target/>
> elements directly, so long term this would be the sane thing to do (for
> MSBuild and for xbuild), but it doesn't address what to do wrt .sln
> files (aside from "replace them", which isn't an option for *current* VS
> users).
>
> This does suggest that (2c) should be dropped (we don't want special
> support for .proj files if .proj may become the new default) and (2e)
> (rather complicated behavior that ankit wasn't thrilled with).
>
> This leaves (2a) (suck it!), (2b) (sane), and (2d).  I don't like (2d)
> because it requires mucking with a largely undocumented file format.
>
> Ankit also seems to like the (2b) solution as well.
>
> Thoughts?
>
>  - Jon
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>