I am an intern responsible for evaluating the distributed build systems available for Windows and Linux.
I have few limitation which I need to consider before evaluating them
Should be Open Source/ Licensed (less preferably)
Supports both Win and Linux
Support CMake
So far I have evaluated FastBuild & Bazel but they couldn't match my requirements.
I am evaluating Incredibuild now but it's licensed and costly :(
As I am running out of the options please help me with few option/tools for build distribution which fulfil my requirements.
Thanks in Advance!
Your support will be greatly appreciated.
Related
Up front: I am not a system adminstrator and my knowledge of FreeBSD-administration is targeted towards getting the programs I have written running.
I've started out with a single FreeBSD machine. Now I've got four up and running. From the start I've used the ports tree for installations.
I'd love to run something like a centralized build and distribution system. There must be some professional term for such a thing, but I seriously don't know. If I would, I would propably be able to find the right infomation.
And that's the question: how (i.e. which tools and/or processes does it take) can I build and distribute FreeBSD binaries from a centralized system?
You should use something like poudriere or tinderbox to manage your build environments. You should be doing parallel builds; distcc allows you to do simple distributed builds and ccache provides a speed-up by caching results.
Once you get the builds working, you just need to export the generated packages.
Here's a how-to for poudriere: https://github.com/freebsd/poudriere/wiki/pkg_repos
My aim is to use Apache thrift on one of our device having vxWorks 6.8 (C++).
I need steps to build thrift lib(.so) or sample application on vxWorks. It would be great help if someone could suggest way out. I am using Windriver Workbench 3.2 on windows 7 and target is PENTIUM3gnu. I can use boost but not C++ 11.
Well, as someone who had to make Thrift build on a bog-normal Fedora PC, and as someone who knows the pain of making it work on embedded platforms¹, I can assure you that your confusion is at least partly caused by Thrift's sub-par build system.
I can't actually give you detailed descriptions on how to build it on vxWorks, but here's the general consensus on what needs to be done when building it on something that doesn't happen to be very similar to the maintainer's machines:
massage all the ./configure options, and explicitly disable every single thing you don't need. Even after much script fixing, I couldn't build the examples/tutorials, so I had to disable them
explicitly state dependency paths. The autoconfigure scripts seem to have been modified in a manner that makes auto-detection of libraries work worse than it normally does with autoconf
try to build. Find the places where for some reasons, the build system uses hardwired locations and hence fails
rinse, repeat.
¹ OpenEmbedded, Android
has anyone using maven-nar-plugin to build C++ code for different platforms, using different compilers? If there is someone please give me more info regarding this.
I am just wondering how can be a NAR file built for different platforms with maven. I know that in order to be able to build a project on a specific platform you should run the build on that platform, and use the specific compilers and linkers of that platform. But my experience is related to Java projects and Maven and as you already know java is pretty platform portable so I've not experienced problems like thin until now.
So, any help and details about how to build projects with maven-nar-plugin would be appreaciated!
Thanks
Currently, the most surefire way to build multiple platform binaries with maven-nar-plugin is to actually do it on different platforms, rather than attempting a cross-compilation-based solution.
For example, the ImageJ project uses maven-nar-plugin to build a small native launcher for Linux, OS X and Windows, 32-bit and 64-bit versions.
To accomplish this, the project has a Jenkins CIS on a Linux server, a Windows 7 64-bit VM in VirtualBox with a Jenkins slave, and an OS X desktop Jenkins slave, each of which performs the Maven build for its respective platforms.
It was quite involved to set up; there are detailed instructions in this ticket of the ImageJ issue tracker.
On a related note, a group of interested developers have recently resurrected maven-nar-plugin, migrating the official repository to a new maven-nar organization. One of the items of interest is cross-compilation, which would make it easier to build native binaries for multiple AOLs on the same platform without resorting to Jenkins slaves. But there are many challenges (e.g., GCC changes behavior often), and it is not yet easy to do. We invite interested developers to join the discussion on the new maven-nar-plugin mailing list!
EDIT 2012.03.02: updated build tool section with some other requirements. Addding premake.
EDIT 2012.03.05: updated build tool section. Focused on CMake. Added Ant + CMakeAnt.
I have a lot of small Visual C++ projects and I want to start using continuous integration for that. A lot of tools are involved in the process. I start reading articles here and there and it is hard for me to see which to tool could integrate nicely with the others. So I am looking for an already tested continuous integration workflow that could respect my needs:
Current Context
C++/Qt applications developed with Visual Studio;
Less than 1'000 source files;
Small dev team;
Small budget;
Preferably open source/free software;
Looking for easy to use and simple tools. No need of something heavy and "powerful".
Finally packages software (installers ready for download) should work for windows and OSX. Linux (most popular distributions) is a plus.
Tools needed
Continuous Integration Server:
Needs to be Jenkins. I know it and I like it. I could change for another one if it is really needed.
Source Code Management:
GIT.
Documentation Generator:
Doxygen.
Build Tool:
We will need to generate solutions and configurations for all the platforms we need to support. I have been strongly advised to use CMake for that. Ant + CMakeAnt (http://code.google.com/p/cmakeant/) seems to be a nice addition too.
Unit Testing Framework:
CPPunit, C++Test, Googletest?
Installers Builder
CPack (part of CMake seems great too).
Hardware:
Preferably, one single machine with VirtualBox or VMWare. is it only possible? Would it be better to use Linux for such things? Or would a MAC mini be sufficient?
So, has anyone here already built something similar? With which tools exactly?
Thanks for any comments and suggestions.
I have successfully used CMake/CTest/CPack with Jenkins, there is a CMake builder plugin available.
I found the ctest --output-on-failure option to be useful as the output from the test is shown in the Jenkins log on failure.
I use the Boost.Test framework for testing C++, it works fine with ctest, I run it with the -l all option to get all the logging output when something goes wrong.
You should be able to bootstrap the entire process using a bunch of scripts.
Write them in Perl or Python. There are a million tutorials on how to bootstrap these sorts of processes.
If you're stuck on implementing a specific party of this build-process, ask a specific question about it.
My company is thinking of dumping InstallShield and move to something else, mainly because of the poor experience it had with it, mostly on Linux.
Our product is a C++ application (binaries, shared libraries) targeted at Windows and Linux (Red Hat).
The installer itself isn't required to do anything special, just dump some binaries and shared libraries and sometime execute an external process. Things like version upgrading through the installer isn't necessary, this is handled after the installer finishes.
I thought of suggesting using NSIS on Windows and RPM on Linux.
What are the recommended installer systems to use when deploying to Windows/Linux? Something that is cross platform to prevent maintaining two installers is a definite plus.
For Windows I would definitively use NSIS. It's very lightweight, easy to code and very simple to understand. Using msis would just be a killer - it generates guid for every file so you can get upgrades for free and stuff but truth being said, you never end up using any of these.
Regarding Linux I would go for RPM and Deb. They're probably the two biggest packaging system so you'll be targeting most of the Linux users. I've never tried RPM but creating a Deb package is fairly straightforward.
See also:
What to use for creating a quick and light setup file?
Packaging to use to deploy cross-platform?
And even:
Creating installers for complex cross-platform programs
There's a tool called BitRock Installer which can create installers for Windows, Linux and OS X.
However, I think that if you target RedHat it would be better to provide native packages for that platform (that is .rpm).
For C++ projects, I'd go with cmake/cpack, if you are also willing to change your build system. Great support, strongly cross-platform. cpack has various generators, NSIS is one..
Take a look at InstallJammer. It will handle both platforms from the same build project, and you can have the installer register the package with the RPM database as well if that's your requirement.
You may want to consider our tool BitRock InstallBuilder , it can generate installers for Windows and Linux from a single project file and also RPMs. Is your application based on Qt? Our clients include the makers of Qt, Nokia (previously Trolltech) and they use it to package their Qt Creator product. We encourage to give InstallBuilder a try and contact our support with any questions or suggestions you may have.