I know. We can do it in perl. Oh wait its not 1995. But seriously there are many options for compiling and building a project but perhaps a wiki of some kind would be a better place to capture requirements and detail what solutions meet those requirements.
And a few points on choices (and sorry if i am stating the obvious) -avoid choosing a dying technology -avoid absorbing a project and customising it. I think the castle project already has a large enough scope -choose something that is a balance of simplicity for the consumer and simplicity for the castle developer. And on this point i err on the side of the consumer. -no matter what your choose ensure that there is a VS sln and you can hit F5 to run it. VS is the one common denominator. User who want to evaluate, debug or contribute to castle (or part there of) will first try to do so with VS. The wont read the README.txt they wont run the "ClickToBuild.cmd" they will find the first file that ends with ".sln" and double click it. -VS on its own will never be the only part of the solution. It is simply not mature enough and does not have the feature required to build a complex project. Hope i have helped and keep up the great work :) On Mon, Dec 21, 2009 at 9:54 PM, Markus Ewald <[email protected]> wrote: > > On 20.12.2009 18:03, Krzysztof Koźmic wrote: > > It's not maintained anymore - well -is that really a problem? So isn't > NAnt AFAIC? > > NAnt continues to be actively developed. They make a new release every other > month on average (okay, the latest is six months old now :P) > > Their problem is that they haven't made a /stable/ release for like two > years now. This doesn't give people the confidence that the project is well > and healthy, even if the nightly builds appear rock-stable. > > On 21.12.2009 10:45, Julian Birch wrote: > My 2 pence: > > I've never seen a csproj-based open source solution that didn't have > reference issues. > > What put me off MSBuild was that Microsoft's build scripts always go down > all referenced projects. > > Imagine you had this: > > Utility.csproj > FooLibrary.csproj (uses Utility) > BarLibrary.csproj (uses Bar) > > Now go into each csproj's directory and type msbuild <project> /t:Rebuild > /p:Configuration=Release > What happens? > > - Utility will be cleaned and built > - Utility will be cleaned and built again, then FooLibrary > - Utility will be cleaned and build yet again, then BarLibrary > > Not only was Utility built three times, if you have any kind of automatic > build version incrementing going on, FooLibrary and BarLibrary will now be > compiled with different versions of the Utility project. So /t:Rebuild is > completely useless. With /t:Build, it only checks each referenced project > recursively on whether it's up to date a few dozen times. > > There sure is some way around it (Visual Studio can to a "Rebuild All" just > fine), but MSBuild wasn't exactly easy to understand so personally I just > used NAnt. I'm following this discussion with interest, maybe I should take > a look at Bake, too :) > > -Markus- > > > > > > -- > > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
