We are looking for adequate build tool for a desktop GUI application to be written in D (using Qt toolkit), consisting of several native libraries, using 3rd party C-lib(s). It has to build on Linux (native development) and Mac as well on Windows. We might adopt Code::Blocks as IDE.
Waf already has support for D language, while CMake is just receiving it cmaked2.
CMake uses special language, while Waf is pure Python...Otoh, CMake, via CPack, can produce packages in several formats as well as GUI installer for e.g. Windoze.
Any pro/cons and what would you use?
We excluded Scons for speed reasons and autoconf, so, please, advice against CMake/waf only.
Update: Although not received any reply here, we were researching in other places, did some reading & testing and decided to use Waf (1.6. release is just around the corner).
Waf is very fast and has been chosen as the build system for Samba (http://samba.org/). It is also used by many proprietary projects because it lets you do crazy things that are impossible in Make/CMake.
I would/do use CMake
I've seen CMake used in many more places than Waf. Most importantly the KDE project is now using CMake.
I did some research on google code search:
there are 2,097 wscript files in various opensource projects
compared to 36,914 CMakeLists.txt.
So CMake is definitely more popular.
I also tried to use google trends to see which was gaining more traction CMake or Waf. I wasn't succesful as Waf is too general at term (ie Wife Acceptance Factor), and "Waf build" doesn't show up in google trends at all.
Scons is known to have terrible performance issues. As Waf is a Scons derived I worry about its performance.
Lastly, CMake has terrible syntax and Waf has beautiful syntax. Since you're going with D it looks like you're willing to go off the beaten path for superior tools. In that case Waf may be the perfect fit.
Related
Are there specific tools are used to configure, build and install source programs?
Lots of different specific tools depending on the platform, language(s) and frameworks you may be using...
As almost all my development is in compiled languages on unix systems, I mostly use make which many people will tell you is sufficiently old these days that you shouldn't clean the patina off lest you ruin it's value at auction...
I'm curious if anyone else has a good recommendation for a Qt friendly toolchain.
We're currently evaluating using The following:
Bug/Issue Tracking - Atlassian JIRA (already in use)
IDE - Qt Creator (already in use)
Code Coverage - gcov (are there easy ways to integrate this into the dev/CI environment?)
Unit Testing - QTestLib and Boost Test
Code Review - Either Atlassian Crucible (expensive) or ReviewBoard (free)
Nightly build/check-in build - Hudson, CruisControl or Atlassian Bamboo. Any advice?
Code Analysis/Style Checker - Vera++? CppCheck? Any suggestions?
Source Code monitoring - Atlassian Fisheye (only if we go with Crucible), ViewVC. Any advice?
Are there any other tools I should take a look at?
Thanks!
Bugs: Bugzilla
IDE: QtCreator but many people will hate you if you enforce the use of one ide over the other, specially if you have opensource developers.
Code Coverage: In order to use gcov for code coverage, your ci environment needs to build the software with appropriate set of flags and execute the code. Also do note that gcov itself does not do any reporting, you need something like lcov to then actually generate the statistics from gcov generated files.
NightlyBuilds: TeamCity, but if you have time to invest and you do want flexbility: BuildBot.
CodeReview: Review board is quite good.
A .pro based build framework will allow your developers to use their own preferred IDE
AQtime is a decent profiler and leak checker
SourceMonitor provides some nice metrics
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
A few years ago I looked into using some build system that isnt Make, and tools like CMake and SCons seemed pretty primitive. I'd like to find out if the situation has improved. So, under the following criteria, what is currently the best build tool:
platform agnostic: should work on windows, linux, mac
language agnostic: should have built-in support for common things like building C/C++ and other static langs. I guess it doesn't need to support the full autotools suite.
extensible: I need to be able to write rules to generate files, like from restructuredText, latex, custom formats, etc. I dont really care what language I have to write the rules in, but I would prefer a real language rather than a DSL.
I would prefer to avoid writing any XML by hand, which I think for example ant requires.
Freely available (preferably open source)
The term "best" is slightly subjective, but I think answers can be rated objectively by the criteria above.
I'd definitively put my vote up for premake. Although it is not as powerful as it's older brothers, it's main advantage is absurd simplicity and ease of use. Makes writing multi-compiler, multi-platform code a breeze, and natively generates Visual Studio solutions, XCode projects, Makefiles, and others, without any additional work needed.
So, judging purely by the criteria set forth in the question, the build system that seems like the best fit is probably waf - pure Python, provides support for C++ and other languages, general, powerful, not a DSL.
However, from my personal experience, I prefer CMake for C++ projects. (I tried CMake, SCons, and waf, and liked them in roughly that order). CMake is a general solution, but it has built-in support for C++ that makes it nicer than a more generic solution when you're actually doing C++.
CMake's build model for C++ is more declarative and less imperative, and thus, to me, easier to use. The CMake language syntax isn't great, but a declarative build with odd syntax beats an imperative build in Python. Of the three, CMake also seems to have the best support for "advanced" things like precompiled headers. Setting up precompiled headers reduced my rebuild time by about 70%.
Other pluses for CMake include decent documentation and a sizable community. Many open source libraries have CMake build files either in-tree or provided by the CMake community. There are major projects that already use CMake (OGRE comes to mind), and other major projects, like Boost and LLVM, are in the process of moving to CMake.
Part of the issue I found when experimenting with build systems is that I was trying to build a NPAPI plugin on OS X, and it turns out that very few build systems are set up to give XCode the exact combination of flags required to do so. CMake, recognizing that XCode is a complex and moving target, provides a hook for manually setting commands in generated XCode projects (and Visual Studio, I think). This is Very Smart as far as I'm concerned.
Whether you're building a library or an application may also determine which build system is best. Boost still uses a jam-based system, in part because it provides the most comprehensive support for managing build types that are more complex than "Debug" and "Release." Most boost libraries have five or six different versions, especially on Windows, anticipating people needing compatible libraries that link against different versions of the CRT.
I didn't have any problems with CMake on Windows, but of course your mileage may vary. There's a decent GUI for setting up build dependencies, though it's clunky to use for rebuilds. Luckily there's also a command-line client. What I've settled on so far is to have a thin wrapper Makefile that invokes CMake from an objdir; CMake then generates Makefiles in the objdir, and the original Makefile uses them to do the build. This ensures that people don't accidentally invoke CMake from the source directory and clutter up their repository. Combined with MinGW, this "CMake sandwich" provides a remarkably consistent cross-platform build experience!
Of course that depends on what your priorities are. If you are looking primarily for ease of use, there are at least two new build systems that hook into the filesystem to automatically track dependencies in a language agnostic fashion.
One is tup:
http://gittup.org/tup/
and the other is fabricate:
http://code.google.com/p/fabricate/
The one that seems to be the best performing, portable, and mature (and the one I have actually used) is tup. The guy who wrote it even maintains a toy linux distro where everything is a git submodule, and everything (including the kernel) is build with tup. From what I've read about the kernel's build system, this is quite an accomplishment.
Also, Tup cleans up old targets and other cruft, and can automatically maintain your .gitignore files. The result is that it becomes trivial to experiment with the layout and names of your targets, and you can confidently jump between git revisions without rebuilding everything. It's written in C.
If you know haskell and are looking for something for very advanced use cases, check out shake:
http://community.haskell.org/~ndm/shake/
Update: I haven't tried it, but this new "buildsome" tool also hooks into the filesystem, and was inspired by tup, so is relevant:
https://github.com/ElastiLotem/buildsome
CMake
CMake is an extensible, open-source
system that manages the build process
in an operating system and in a
compiler-independent manner.
Gradle seems to match all the criteria mentioned above.
It's a build system which took the best of Maven and Ant combined. To me, that's the best.
The Selenium project is moving over to Rake, not because its the best but because it handles multiple languages slightly better than all the other build tools and is cross platform (developed in Ruby).
All build tools have their issues and people learn to live with them. Something that runs on the JVM tends to be really good for building apps so Ant, Maven (i know its hideous), Ivy, Rake
Final Builder is well known in Windows world
smooth build matches most of your requirements.
platform agnostic: yes, it's written in java
language agnostic: it doesn't support c/c++t yet, only java but it is extensible via plugins written in java so adding more compilers support is not a problem
extensible: yes, you can implement smooth function via java plugin, you can also create smooth function via defining it as expression built of other smooth functions.
I would prefer to avoid writing any XML: you won't see a single line of it in smooth build
Freely available: yes, Apache 2 license
disclosure: I'm the author of smooth build.
I'm working on transitioning my current project of about 20 developers to a modern development and build environment. We currently use an RCS based source control system and an associated issue tracking system, both with Motif UIs. There is no formal production build process, its just whatever works.
I'm interested in:
Development Tools
Version Control
Issue Tracking
Dependency Management
Configuration Management
Automated Building
Automated Testing
Continuous Integration
Artifact Management
Release Management
Deployment Management
Requirements Tracing
What else?
I'm interested in not just which tools you use, but how well the integrate with each other, how easy they are to setup and use, and how both developers and management likes them. Our project is a combination of Java, C++, and VHDL, but I'd still like to hear from people with other languages. I'm currently going down the path of eclipse, subversion, trac, maven, hudson, and nexus.
Also, is there a better term than "Build Lifecycle" that encompasses not just building, but the flow of code from when the developer creates it to when its built, tested, and in a production system? "Build Lifecycle" seems limited, but "Project Lifecycle" is already taken.
I hate Maven less than I hate Ant, and for Java, you need to choose one of those evils. If you're just starting out, choose Maven, especially since you've already recognized that your "build lifecycle" encompasses 12 different and complex disciplines! You're going to have to choose conventions for all of them. Save yourself the trouble and go with the conventions Maven has already established.
For continuous integration and general build automation, I like Hudson.
During the last two years we gradually switched from a "every-project-has-its-own-toolset" strategy to a Trac+SVN+SCons solution and are quite happy with that.
Switching to SCons was a bit of work but really paid off. We have a heterogeneous environment, mostly C/C++ for different embedded platforms, kernel modules, some desktop applications and various Python modules as glue code. SCons really shines when you want to add support for your own compilers and niche-tools and need to adapt the build system to your requirements. Formerly, we had to use a different GUI for almost every embedded platform - now that SCons directly invokes the compilers the work-cycle has slightly improved.
Our developers either used Emacs or Vim and no one wanted to switch to anything else, so we (fortunately) sticked with that. I'm not very familiar with deployment so I can't talk about that.
If you work with .NET, it's hard to beat Team Foundation Server for its integration with Visual Studio. It contains the development tools, version control, issue tracking, configuration management, automated testing, unit testing, automated building, artifact management and everything else you've described.
Of course, TFS is expensive, oftentimes non-intuitive and is missing some features compared to other tools I've used. If you have a MSDN license you can use TFS for Workgroups (up to 5 users IIRC) for free, though.
Development Tools JetBrains IntelliJ IDEA
Version Control Subversion
Issue Tracking Atlassian Jira
Dependency Management Maven
Configuration Management TeamCity
Automated Building TeamCity
Automated Testing JUnit(?)
Continuous Integration TeamCity
Artifact Management Maven
Release Management Homo Sapien
Deployment Management Maven/Homo Sapien
Requirements Tracing Wishful thinking
One-Off Automation Bash
Developer-to-Developer Documentation MediaWiki
We're an MS shop using VS2008. We use Subversion with Tortoise for SCC and versioning, and our repository is hosted online so our distibuted team can use it. For build we're using Hudson and CI, much better than Nant or MSBuild. Issue tracking is Bugzilla. Automated testing is NUnit
Tools to avoid include Team Foundation Server and Sharepoint, too clunky for real world usage.
BTW Does anyone know a good Scrum tool, which can produce burn down charts, ideally linking into Basecamp?
We also use a number of tools, but we're moving more and more to Zed Builds & Bugs. Our primary dev environment is Eclipse + Java, but we also do Visual Studio (all of 'em), and at least 5 different unix platform builds.
Here's the full list:
Development Tools - Eclipse
Version Control - Subversion
Issue Tracking - Zed Builds & Bugs
Dependency Management - Ant
Configuration Management - Zed Builds & Bugs
Automated Building - Zed Builds & Bugs
Automated Testing - JUnit
Continuous Integration - Zed Builds & Bugs
Artifact Management - Zed Builds & Bugs
Release Management - Zed Builds & Bugs
Deployment Management - Zed Builds & Bugs
Requirements Tracing - Zed Builds & Bugs
One-Off Automation - Zed Builds & Bugs
Developer-to-Developer - Zed Builds & Bugs
I use svn and tac on some oof my projects and svn and fogbugz on others. They integrate very well.
I am still using command line scripts for builds as they do everything I need - including grepping for errors and emailing results, but the days of that setup are numbered. I am looking into cross-platform build tools.
I use Inno for win32 releases. No shipping products yet for other platform - not sure how we'll deploy those.
We don't address a lot of the other items you mention other than on some ancillary documentation and in the code and in issue tracking.
Team Foundation Server and Visual Studio.
I remember when my ide was Sun's visual C debugger, and source control was copying all source files to a new named directory and putting it on a server that was supposed to be backed up.
Only it wasn't
Each project using SCons seems to be reinventing the wheel.
I would be glad to take someones directory layout, and/or solution for variant builds(debug/release), and/or testing framework, and/or best practices.
Even several not-too-simple examples would help.
You may be interested in Google's Software Construction Toolkit that was made open source in February 2009. It adds new features on top of SCons, such as improved Visual Studio project file generation, unit test functions, and distributed builds with distcc or incredibuild.
The SCons Recipes in the wiki is a good place to start. In addition take a look at other projects which use SCons, e.g. the Ardour build system. If that doesn't cut it, there are a few third party SCons extensions you may want to take a look at:
Parts
Aqualid
To the best of my knowledge, there are no SCons best practices which were agreed upon. The SCons community seems to favor adaptability over "canonicalization". It is not hard to design a decent SCons-based build system from scratch, though. (Once you have understood how VariantDir works, at least.)
If you are using Eclipse for C++ development you may want to check out this SCons builder plugin (http://nic-nac-project.org/~lothar/eclipse/update/SConsBuilderPlugin.html)
Another good example of SCons use is build system for MIT-licensed Godot game engine:
https://github.com/okamstudio/godot/wiki/compiling_intro