[Mono-dev] xbuild usability

[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 <jonpryor at vt.edu> 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
>
>
>