Hello!
My project should build on different platforms besides Linux which will be native one.
Of course, one possibility is to just provide Installers for end-users, but I'd still like to test the code, at least under Windows (XP running under virtualbox) cause I don't have access to Mac OS X.
Besides Nimrod code covering GUI part, I plan to have several custom libraries written in Nimrod which should call 3rd party C library (Swiss Ephemeris) for which we need to provide Nimrod bindings.
This library is not often available on the end-user's system, so very often the applications which make use of it are including its source allong with their code.
Moreover, I can envision having documentation (e.g. user manual) written in reST/Sphinx, so wonder if the Nimrod's build system is capable to build the whole projects, iow:
Having experience and evaluating several build systems starting with autoconf and then via premake/scons/waf/cmake/tup...I prefer the solution which is the most elegant & simple...that's. btw. one of the reasons we picked Nimrod as well. ;)
Any hint?
Araq wrote: "We have no such build tool. I'd write a build script in Nimrod instead."
Yeah, this is one option. Otoh, considering that Nimrod takes care about interoperability with C (recent thread about null-terminated strings) it would be nice to have in the build system ability to build C sources for which one wants to provide native Nimrod bindings and have "interoperability with C".
Hey check out Nake, you could use it to do the stuff you need, not automagically but a lot more maintainable than make/autoconf scripts https://gist.github.com/fowlmouth/3607822
task "build-dependencies", "Build the required C libs":
withDir "build":
withDir "lib1":
shell "./configure"
if shell("make") != 0:
quit "Building lib1 failed ..."
const ExeName = "main"
const releaseDefines = "-d:release -deadCodeElim:on"
const testDefines = "-d:testfeature1 -d:debug --forceBuild"
const profileDefines = testDefines & " --profiler:on --stacktrace:on"
task "test-build", "build with test features":
shell "nimrod", "c", testDefines, ExeName
Much as I understand the desire to avoid using cmake, auto-tools etc, there are times where sticking to tried and tested methods have their advantage.
In my company, which I must say is embarrassingly, large, lumbering and slow to adopt new changes, we have just managed to move to cmake. I really needed a way to get nimrod running within the build-env that is deployed.
Here's my quick hack at it.
https://gist.github.com/shiva/521536ddea6425025606
Comments?
I have used SCons in the past, but now I am mainly using Google Waf (https://code.google.com/p/waf/). Like SCons, it is a Python-based, language-agnostic solution which is extremely easy to use. It comes with some nice documentation ("The Waf book", http://docs.waf.googlecode.com/git/book_16/single.html). Moreover, deploying it on other systems is extremely easy: just download the "waf" script and put it wherever you want.
The main reason why I prefer Waf over SCons is that builds seem much faster. (See the SCons wiki: http://www.scons.org/wiki/SconsVsOtherBuildTools#Waf .)
Araq: IMO we should get Nim's interpreter ("interactive mode") to the point it runs Nake (maybe it already works?) and add Nake to the distribution.
The point in using an existing build system is when you want to use Nim in a hybrid system (otherwise, there shouldn't be much need for a build tool, at least not yet). Maintaining stuff like how (for example) a dynamically loadable C library is being build (where to find the tools, which command line options these tools need, how to figure out dependencies) is not a whole lot of fun (not to mention, can break fast without actively being maintained). There are other tools that have already done that work.
Raw dependency management tools without that built-in knowledge are a dime a dozen and that would just be reinventing the wheel.
Jehan said: The point in using an existing build system is when you want to use Nim in a hybrid system [...]
Ok, fair enough, but then it's not a question of what to support really. Nim support should then be added to any existing build system that's of interest to somebody.
Araq: Nim support should then be added to any existing build system that's of interest to somebody.
The only support you really need is dependency checking. And that is essentially just having the executable depend on *.nim, since Nimrod can't even compile part of a project (yet?). As long as you have wildcard support, that's fine. Far more important would be the following:
Makefiles and such are primarily for languages like C, where compilers don't know about dependencies and they have to be retrofitted. In principle, nim compile is already a build system.