We are trying to automate the C++ (VS 2008) code build using Jenkins. I have used Cmake with Unix makefiles as the generator and have completed generating the makefile but post that when i use make all from the build directory.
Now make all with "all" as that is the default target, there is no executable that gets generated and the Jenkins jobs shows as success but i cannot see the executable in any of the folders in the workspace.
I have tried to wipe out workspace and then executed still the build fails.
Is there something obvious that i have missed. Please help me..
Thanks
Shalini
Related
I am trying to build a large C++ framework in VSCode using CMakeTools and C/C++ Extensions in Visual Studio Code. I am browsing stackoverflow/github issues/any google suggestion and it looks like I am not the first person to encounter this, but I can not figure out for the life of me what am I doing wrong.
Here is the problem. I want to setup VSCode in a way to be able to build the framework (it is C++) right from VSCode using the built-in tools/extensions. Here is the process I was using up until now (in standard terminal in linux) and it also works in terminal run in VSCode:
cd /path-to-project-main-folder
source scripts/env.sh
cmake .
make -j 10
Now the problem is that when I set up VSCode, open the folder where the framework is, VSCode recognizes it is cmake project and gives me the opportunity to build it. Problem is that when I try to build it, it does not set up the environment first and therefore uses wrong cmake (not the sourced one but the default one build in server) and also wrong libraries and some of them are not even recognized.
The problem is in the first line:
source scripts/env.sh
where the environment variables are set and also PATHs to some libraries and programs. This line is not ran by VSCode before cmake and build.
Does anyone know a solution on how to configure CMakeTools extension to run:
source scripts/env.sh
line before running cmake and then make?
Thank you
I was looking into some solutions using tasks.json, settings.json files or creating my own kit. But no solution worked for me or I did not completely undestood the solution:
https://github.com/microsoft/vscode-cmake-tools/blob/HEAD/docs/tasks.md
https://github.com/microsoft/vscode-cmake-tools/issues/2243
https://github.com/microsoft/vscode-cmake-tools/pull/995
VSCode: Set environment variables via script
and man pages of CMakeTools, VSCode,...
VScode remote development: How can I run a build task to source environment variables before running the real build task? ---> but I use cmake
VSCode, how to source environment variable files like setup.bash?
I have a build engine from ARM, called yotta. I have been working with the command line, where with the following commands, I can build projects and produce outputs.
$ yt target bbc-microbit-gcc
$ yt build
The compiled file is then accessible from build/bbc-microbit-gcc/source/Project-name-combined.hex
Is it possible to automate this CLI and build it into Visual Studio as a build definition? I know in Visual Studio Team Services / Team Foundation Server), you can define build steps using the command line, what is the local equivalent.
I am using Visual Studio Enterprise 2015. Any nudge in the right direction would be much appreciated.
EDIT:
I have seen the GCC4mbed project, but it would be good to use the new yotta command line build to do this. As far as VS is concerned is a command line tool which adds a built version of the project to a directory, a build tool? If so, then I know I can just follow the guides to add a custom build tool to VS however, it strikes me that VS might need a build tool to be in a certain standard to make intellisense etc work. In which case I might need to create a build tool on top of the existing yotta work and specify this to VS? Ideas would be muuch appreciated.
did you try to use cmake generators option which yotta provides (as it uses CMake)?
yotta build --help
-G CMAKE_GENERATOR, --cmake-generator CMAKE_GENERATOR
CMake generator to use (defaults to Ninja). You can use this to generate IDE project files instead, see cmake --help
The ideal solution which implemented partially as VS debug engine is still under development, just recently allowed gdb extensions. The tool on top of yotta for debugging is called Valinor (which is using progen: https://github.com/project-generator/project_generator).
Progen supports visual studio gdb (its very limited at the moment as explained later). I was able to use yotta debug with visual studio, but not without hacks (dated back in November-December 2015). The idea was to have a visual studio project with gdb setup and custom build commands (make,cmake or yotta) (in our case would be pyOCD settings, could be openOCD or jlinkGDB, and built environment for yotta).
As I recall, you commented on the issue on https://github.com/project-generator/project_generator/issues/98, and I haven't heard back from you. The problems I had I recall was I could not start gdb server (I had to do it manually), I could not make it to pass arguments to gdb (like load/reset/halt when starting the session).
I'll update my VS plugins and check if there were any updates in gdb plugins, I was told there should be.
I appreciate any help, either for progen or valinor to make this available for users.
I'm not a Windows 8 developer so excuse any stupid questions.
I have a Windows 8.1 application built in Visual Studio 2013 via a .sln file. This contains a number of projects: there is an application that relies on a library, this library (call it datalib) is built as a Windows Runtime Component (not a DLL);
there is also a test project which runs tests on 'datalib'
All of this works fine in VS2013, i.e. the tests execute.
I've been tasked with creating a TeamCity build for this so I've create a TeamCity build that builds against the sln file but I can't get the tests to execute (they're MSTest tests).
In my configuration I've added the test.dll (in the 'include assembly files list') but when I add this on it's own then I get a bunch of errors around references to types in the 'datalib'
The 'datalib' is built into datalib.winmd (I'm assuming this is the binary) so I thought that including this in the assembly list would fix my problem, but it doesn't.
I assume I'm missing something simple, what is it?
I'm now able to do this and it was a multi step process.
Firstly you don't load/test the winmd file directly you have to load the appx that's created by the test project 1; you can't use the MSTest runner that comes with TeamCity, instead you have to install the Visual Studio Test Runner plugin [2]; you have to run the build agent in an interactive process; and finally you have to install the root certificate that the application was signed with.
You reference the appx like you would a DLL
To install the build agent and have it run interactively it wasn't good enough to use the service and mark 'Interact with Desktop' you need to have full interaction so the agent has to be run from the desktop, as admin, at startup. To do this I had to create a scheduled task that run at startup and was given full privileges.
I installed the cert by running the ps1 file in the same directory as the appx file (Add-AppDevPackage.ps1) I'm sure this is overkill but it seemed like the easiest option at the time
[1] http://msdn.microsoft.com/en-us/library/hh691189.aspx
[2] https://confluence.jetbrains.com/display/TW/VSTest.Console+Runner
I have a solution in VS2010 (C++ code) that includes test files directly in the src and include folders for the project of a plug-in. I am using Google Test framework. The plug-in, let's call it myPlugin, is running on a software, say mySoft.
######################################################################
Here is the issue:
I can run tests with command line, ok.
But i would like to debug inside the GTESTs. Why ? Because the tests are not really unit tests, they are setting a lot of parameters, and i would like to check step by step that everything is set ok. I know this is not mandatory to solve this and that i can debug the application itself. Anyway, this is my question, i want to debug inside a gtest.
I try to config VS2010 properties so as to launch the tests from VS, and this is not working.
############################################################################
More details:
To run the tests, i have to have an executable launched. In other words, i am running tests while an application, mySoft.exe, is running. The plug-in is running using another executable, the sdk_mySoft.exe.
The command lines (that work) are
mySoft.exe -sdkRun=pluginLevel ;pluginDirName;version;myPlugin_x64.dll
--gtest_output=xml
-sdkRun is in-house command offered by the sdk to set up GTests. So here i launch my application, run the plug-in, get some logs from google test, ok.
Then, I try to configure VS with these debugging properties:
Command $(SolutionDir)\bin64\mySoft.exe
Command Arguments -sdkRun=pluginLevel ;pluginDirName;version;myPlugin_x64.dll
--gtest_output=xml
and here this is not working.
Error is
Debugging information for 'mysoft.exe' cannot be found or does not
match. Cannot find or open the pdb files.
Any idea ?
How to debug in gtest, taking into account the special conditions here: have to launch an application?
Thanks
To debug the GTest, the debugger needs to be linked to application.
Launching the application, click on CTRL gives access to the VS debugger.
I have eclipse and goclipse installed, all is well, I can run a console app in the IDE. It is possible to execute the unit tests in the IDE too?
The latest release of goclipse (0.7.6) does provide a means of doing testing using the "testing" package assuming you have followed the project structure recommended in C:/Go/doc/code.html in the installed file structure created when installing Go.
Using the Eclipse "run external tools" button create a new external tool configuration as follows:
on the Main tab the location is C:/Go/bin/go.exe
the argument is test
the working directory should point to the eclipse workspace folder containing the package that is to be tested (eg ${workspace_loc:/goProject/src/pnp}, where pnp is the name of the package NOT the name of the go file that contains the test).
You can now run the test by pressing the Run button in the usual manner, having given the configuration a sensible name eg: go test pnp. You can now add further tests to the package in different go files (or the same one) and all the tests will be carried out in a manner that is expected.
Yes it is if you make a makefile to do so... If you are asking if goclipse has a built in testing facility like JUnit for java the answer is no though.
The issue 5 was asking to "Integrate 'go test' into the IDE and developer workflow."
It now has just been closed (August 2015), with commit 9c3c858 (next release after 0.11.2), with the following documentation:
Each Go project has 3 built-in Build Targets, which are ways in how the project can be built.
These can be viewed and configured in the Project Explorer:
The modes are:
./... #build: The default build. Builds all Go packages present in the project (excluding test packages).
./... #build-tests: Builds all Go test packages present in the project.
./... #[run-tests]: Builds all and runs Go tests.
Each target can be enabled or disabled when for Eclipse project builds. (There is not much point to have both #build-tests and #[run-tests] enabled though.)