[Mono-dev] xbuild usability
monoman at gmail.com
Thu Nov 5 10:42:17 EST 2009
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."
On Thu, Nov 5, 2009 at 1:23 PM, Jonathan Pryor <jonpryor at vt.edu> wrote:
> 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.
> 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
More information about the Mono-devel-list