xbuild usability

[Jonathan Pryor]

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
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[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 <[hidden email]> 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
> [hidden email]
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Jonathan Pryor]

Below...

On Thu, 2009-11-05 at 10:59 -0200, Rafael Teixeira wrote:
> 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.

I'm not sure I understand how this is "the reverse of 2b."  I'm not
entirely sure I understand how it relates to 2b at all.

The point to 2b was that a (for Mono.Rocks.sln) Mono.Rocks.targets (or
Mono.Rocks.proj file in 2c) would be *merged* with the .proj file
generated from the *.sln file (as both MSBuild and xbuild generate
a .proj file from the .sln instead of directly processing the .sln file;
in VS2008, MSBuild even stores this generated file as e.g.
Mono.Rocks.sln.cache).

So 2b/2c isn't an "instead of" solution, it's an "in addition to"
solution -- *merging* files.

Your approach sounds like an "instead of" solution, or am I misreading?

I don't think we want an "instead of" solution.

 - Jon


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Rafael Teixeira]

OK, probably for me I can just drop the main solution master file and
keep a master .proj, as the "master" solution was a convenience to
enable building from the IDE, without having to load all projects from
all sub-solutions inside a "monster" solution.

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 Thu, Nov 5, 2009 at 1:23 PM, Jonathan Pryor <[hidden email]> wrote:

> Below...
>
> On Thu, 2009-11-05 at 10:59 -0200, Rafael Teixeira wrote:
>> 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.
>
> I'm not sure I understand how this is "the reverse of 2b."  I'm not
> entirely sure I understand how it relates to 2b at all.
>
> The point to 2b was that a (for Mono.Rocks.sln) Mono.Rocks.targets (or
> Mono.Rocks.proj file in 2c) would be *merged* with the .proj file
> generated from the *.sln file (as both MSBuild and xbuild generate
> a .proj file from the .sln instead of directly processing the .sln file;
> in VS2008, MSBuild even stores this generated file as e.g.
> Mono.Rocks.sln.cache).
>
> So 2b/2c isn't an "instead of" solution, it's an "in addition to"
> solution -- *merging* files.
>
> Your approach sounds like an "instead of" solution, or am I misreading?
>
> I don't think we want an "instead of" solution.
>
>  - Jon
>
>
>

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list