I've been trying to migrate my whole test projects to Jenkins which includes both Windows and Qnx C++ codes. Since I'm trying to manage all the continuous integration from the windows platform, I installed jenkins only on the windows machine.
Inside Jenkins, I created 2 different jobs, one for windows related codes and the other for qnx related codes. For windows related codes, there is no problem on building, running and collecting gtest outputs like passed/failed results or code coverage. (I use Visual Studio with OpenCppCoverage tool, so inside Jenkins, msbuild plugin and some windows shell commands are enough to create results for cobertura and junit plugins)
However, for the qnx related part I have the problem:
(For qnx projects I'm using Qnx Momentics) Inside Jenkins, I checkout the project to the windows machine from subversion, and use "mkbuild" command (which works fine for windows). This builds the project automatically and create the executable on windows. But I could not manage to run the executable (on the target qnx machine) to collect the test results from Jenkins.
I have checked many plugins but couldn't find some to solve this problem.
Is there any option to do this?
Thanks in advance :)
One similar question was asked for hudson, and it was proposed there to use virtual machines and creating slaves for each one. Using different slaves may solve the problem, I will try this.
How to use hudson when building for multiple platforms
Related
I can able to use this Jacoco coverage in Windows machine. I want to know whether this works for Linux machine or not. If it works, tell me how. If it doesn't, please tell me the reason.
Thanks.
Jacoco is implemented in Java and usually ran from Maven or Ant or Jenkins, which are also implemented in Java. Java works on both Windows and Linux, so there should not be any issue with running Jacoco in Linux.
You could have issues with running your build, say under Maven, if your pom file definition contains Windows specific paths and settings. This would cause your build process to break, not the Jacoco run. If you manage to have a successful build in Linux then it should easy to get Jacoco to run as well.
Background:
Im using QT and have visual studio 2012 as my IDE (used the QT plugin for visual studio).
And finally the whole project is done. However due to my .NET background I have no experience when it comes to deploying my project so it can be run on Linux.
Question:
Anyone knowing how to deploy a QT project made in visual studio to linux?
You should install Linux and prepare a Qt development environment on it.You can then copy your project there, compile it and see the results in the real environment. This way you can cope with the minor differences when porting from one OS to another easily.
So don't think of cross compiling your app for Linux on Windows. From a complexity point of view, I think setting up a Linux machine (VM or not) and the necessary environment for Qt is a whole lot simpler than cross compiling bug hunting afterwards. After all you will need a real target environment to finally test your application.
Before you can deploy something you have to compile it for that platform, and here you have two main choiches: either you cross-compile which means you compile it on windows using a set of tools so that your software is built to run on a linux, or you get a linux machine, you copy your entire project over and let Qt for linux do the magic.
Once you have your working binary compiled on linux or for linux then you start thnking about deployoment.
If you really want to be fully linux-compatible and "linux-ally correct" you should distribute your source-code precooked using some tools like "automake" that will make it possible to linux users to compile it on any linux version.
If you do not want to release your source code, you technically can distribute binaries without source code (not sure if you will be ok with licenses) but you have to be aware that there is no standard in linux for distributing binary packages, there are at least 2 main package building standards that are the ubuntu/debian style and red hat (and friends) style.
You are going to find plenty of documentation about all this stuff from cross-compile to automake and of course building debian packages and building red hat rpm packages.
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)
We have a smallish C++ Linux project that accompanies our large C++/MFC Windows project. Currently, the Windows project uses CruiseControl.net and Visual Build Pro for managing continuous building and integration. We would like implement something to start our Linux project on the same path.
My question is, should I research using a separate Build tool for Linux or attempt to get Visual Build Pro to work by leveraging its automation and simply invoking a make script on a our Linux Build Machine to actually compile the project?
Even further, due to the size of the Linux project, would it be just easier to script it all including making snapshots and such?
While I don't know the complexity of the "integration" step in your project, the "building" step is in my experience best solved by a trivial shell script:
BUILDDIR=`mktemp -d`
svn checkout MY_REPOSITORY/trunk $BUILDDIR
cd $BUILDDIR
./configure
make all check
I've solved the integration test part with Dejagnu in my current project, works like a charm with another line of sh calling it.
Then insert this shell script into the daily run routine (e.g. by adding it to the crontab of a special CI user on the Linux machine) and forward all of the mail the CI user gets to the person responsible for watching the CI.
You can use jenkins or hudson to build on Linux box. This tools have integration with Source Control (svn, perforce, ...), cppunit ...
How to setup/configure the environment "CDC-1.0/Foundation-1.0,J2SE-1.3" of an OS (for example windows XP, linux)?
Because I want to run the embedded AWT application which requires this environment.
one possibility is to install an IDE which contains all that. the one which seems the most appropriate to me is NetBeans. go and see on their site, there are some tutorials on installation, setup and project creation
note that there may be other IDEs to perform the same task, i am just not aware of them.