rsdn
Build Tool for Nemerle
Many languages have build tools around them.
E.g. Groovy - Gradle Scala - SBT F# - FAKE
It would be a good idea for Nemerle to have one also. Also this would help clean up all the CMD scripts that are needed to build Nemerle itself.
MSBuild forks fine for us. Why we should create replacement for it? All that CMD files are just shortcuts for MSBuild with some known arguments.
No need to replace it as of now but it would be good to have a tool like FAKE for Nemerle. Once this is there it can be used instead of MSBuild.
Nemerle is a .NET programming language, so using MSBuild is the best way. You can build C#, F#, Nemerle, and other .NET languages with the same tool in the same time. Nothing can be greater than that. I don't think FAKE is a good build tool for F# too.
@lambdalice Fake is more than build tool, it's using msbuild (or XBuild because MSbuild is win-only and both Nemerle and F# are not), I think @sirinath is asking exactly about such utility to make it easier to script deploy and other project related things (for example https://github.com/fsharp/FSharp.Compiler.Service/blob/master/build.fsx). But I don't think that we need yet another thing like that specially for Nemerle.
I totally agree with this idea - after using SBT for several months now, I'd like to see something like this for .NET and Nemerle seems like a very good candidate for the project/build scripts.
_SBT_
val someProj = (project in file(".")).settings(...)
_(Insert clever name here) NBT?_
someProj = Project(FilesIn(".")).settings(
assemblyName := "CashMoney", // Specify the output assembly name
Debug.OutputDirectory := Base / ".." / "bin / "Debug", // Specify the output directory for debug configuration
references += "ReactiveFramework" % "1.1.3.457, // Simple to specify Nuget package dependency!
...) - You get the idea.
Instead of porting SBT into .NET, given that there is already so much tooling around MSBuild, I think that a .NET specific build tool which utilizes MSBuild/XBuild makes the most sense, but where all the attributes and "glue" are done in code, with the full power of the .NET CLI at your disposal.
Something like:
- Supports plugins
- Load and modify .*proj files programatically
- Generate "AssemblyInfo.*' files automatically, from a list of Manifest attributes
- Automatically download Nuget packages as a resolution step
- Allow for (but not default behavior) "project-less" builds (where entire structure of project is defined only in code, no .*proj files required), like SBT
- Allow for pre-(MS/X)Build build steps, defined programatically- like: ProjectFiles.filter(f => f.Extension == ".txtdoc").map(a => GenerateXmlDoc(a)) (hypothetical)
- Has a console (Powershell or custom), again like SBT
- Allows for debugging of build scripts (since they are all code)
- Supports "run tests" mode for running tests using some testing framework (shell invoked or roll-your-own-plugin)
If anyone out there interested in creating such a tool, let me know.
Automatically download Nuget packages as a resolution step
MSBuild already can do this.
Supports "run tests" mode for running tests using some testing framework (shell invoked or roll-your-own-plugin)
MSBuild already can do this.
Allows for debugging of build scripts (since they are all code)
So you propose to replace a declarative build with imperative one. Great.
Man, just read MSBuild doc and look for community-provided MSBuild tasks (here is a good start point). It already can do almost everything you need. If you don't know how to use existing build tool, it doesn't mean that it's needed to write a new one from scratch (this statement doesn't apply to GNU autotools however).
You are mistake. I was not enumerating a list of features that MSBuild does not have.
I was listing features that I thought a comprehensive build tool (like SBT, which I will posit to guess you are not familiar with) should have.
I'm quite familiar with how MSBuild works, how to write Tasks, what is possible with the community MSBuild tasks, etc. That is exactly why I think there is a better way.
Like most people, I loathe XML - You can certainly and more succinctly declare your build process / steps in code.