Based on several kits I am using, the Qt Creator build directory is derived from
project name
Qt version
compiler
build configuration: debug / release
Example: build-client-Qt_5_3_0_fooProject_MINGW_32bit_qmake_MinGW22-Debug
My problem is, if I switch my git branch, I always have to recompile from scratch (time consuming). I wonder, if it might be possible to include the branch name, so I can keep different builds at the same time
=> Possible build dirs:
build-client-Qt_5_3_0_fooProject_MINGW_32bit_qmake_MinGW22-Debug_master
build-client-Qt_5_3_0_fooProject_MINGW_32bit_qmake_MinGW22-Debug_branchbar
Or is there a chance to add a third build configuration, e.g. Debug_others, resulting in a build directory such as
build-client-Qt_5_3_0_fooProject_MINGW_32bit_qmake_MinGW22-Debug_others
You can manage builds in Project tab on the left. If you want to have build automaticaly switching dirs depending on the branch you are on, on each branch you would have to edit *.pro.user file. Find line:
<value type="QString" key="ProjectExplorer.BuildConfiguration.BuildDirectory">
/home/etc/etc/etc
</value>
And change the directory to the one you want it to be (ex. edit the ending part of the value). On a different branch have it point somewhere else. Thus changing branches will change the shadow build directory.
P.S. If you have several builds (like debug, release) you need to check if the build directory you're editing is the one you want. Check activeBuildConfiguration number and edit it's directory only (the number of build is usually a line above the one I showed), or change activeBuildConfiguration to 0 and the first build directory.
It's a bit knotty but I think manageable.
Related
Having used CMake, I've become used to out-of-source builds, which are encouraged with CMake. How can out-of-source builds be done with Cargo?
Using in-source-builds again feels like a step backwards:
Development tools need to be configured to ignore paths. Sometimes multiple plugins and development tools - especially using VIM or Emacs!
Some tools can't be configured to easily hide build files. While dotfiles are typically hidden, they will still show Cargo.lock and target/, worse still, recursively exposing their contents.
Deleting un-tracked files to remove everything outside of version control, typically to cleanup editor temp files or some test output, can backfire if you forgot to add a new file to version control and don't manually check the file list properly before deleting them.
Dependencies are downloaded into your source code path, sometimes adding *.rs files in the target directory as part of building indirect deps, so operating on all *.rs files may accidentally pickup other files which aren't in a hidden directory, so might not be ignored even after development tools have been configured.
While it's possible to work around all these issues, I'd rather just have an external build path and keep the source directory pristine.
You can specify the directory of the target/ folder either via configuration file (key build.target-dir) or environment variable (CARGO_TARGET_DIR). Here is an example using a configuration file:
Suppose you want to have a directory ~/work/ in which you want to save the Cargo project (~/work/foo/) and next to it the target directory (~/work/my-target/).
$ cd ~/work
$ cargo new --bin foo
$ mkdir .cargo
$ $EDITOR .cargo/config
Then insert the following into the configuration file:
[build]
target-dir = "./my-target"
If you then build in your normal Cargo project directory:
$ cd foo
$ cargo build
You will notice that there is no target/ dir, but everything is in ~/work/my-target/.
However, the Cargo.lock is still saved inside the Cargo project directory, but that kinda makes sense. For executables, you should check the Cargo.lock file into your git! For libraries, you shouldn't. I guess having to ignore one file is better than having to ignore an entire folder.
Lastly, there are a few caveats to changing the target-dir, which are listed in the PR which introduced the feature.
While useful manually setting this up isn't all that convenient, I wanted to be able to build multiple crates within a source tree, having all of them out-of-source, something that ../target-dir configuration option wouldn't achieve.
Helper utility for convenient out-of-source builds
Using the environment variable I've written a small utility to wrap cargo, so it automatically builds out-of-source, supporting crates both at the top-level, on in a subdirectory of the source tree.
Thanks to Lukas for pointing out CARGO_TARGET_DIR and target-dir configuration option.
What I really wanted was a dynamic CARGO_TARGET_DIR that changes relative to where I am.
This bash alias puts all builds in a mirrored directory structure, e.g. instead of putting target into ~/mydir/myproj it puts in into ~/rustbuild/mydir/myproj
alias cargo='CARGO_TARGET_DIR=$(echo $PWD | sed "s|$HOME|$HOME/rustbuild|g") cargo'
You could also make your rustbuild directory hidden.
When creating a vNext build on TFS 2015 you can define variables, which are then used in build steps, and can also be used as environment variables in scripts the build runs.
The build I am working on runs scripts that pulls files from mapped locations, so it would be great if I could define a variable and use it in a mapping so that for example, if I update a reference in the project the build is building, I can simply update the variable with the new location and have the repository mappings and scripts all pull correctly from the new location without having to make the change in multiple places.
I have tried doing this by setting up the variable and mapping as follows,
But this generates an error when you try to save the build complaining that there are two '$' characters in the mapping. Is there way to do this or is this not currently possible?
This has been causing me havok for quite a while as well.
For starters, there is a uservoice request for this feature. You can add your votes and input here to get Microsoft to allow this feature: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/14131002-allow-variables-in-repository-variables-and-trigg
Second, we've developed a workaround that gets us most of the way there. It's not perfect, but it might be useful to you if you're comfortable with the tradeoffs or can work around the deficiencies.
Start by turning off the "Label Sources" option of the build and mapping the Server Path field to you base build. You'll want to add a custom variable to the Build Definition to tell the build instance what TFS location to pull from. For example, we have a base project and then multiple branches from the project, so our source is structured like this
$\Team Project\Project1
$\Team Project\Project1Branch1
$\Team Project\Project1Branch2
$\Team Project\Project1Branch3
and we create a variable named "Branch" that we can set to "Branch1", "Branch2", and so forth.
When we want to build the base project, we leave the Branch variable blank when launching the build. For branch builds, we set it to the name of the branch we want to build.
Then our build steps look like this
Remap Workspace Folder to Branch Folder
Get Files for Specified Branch - We have to do this manually after
remapping our workspace
Compile the Source in the Specified Branch
Publish Build Artifacts from the Specified Branch
Label the Code of the Specified Branch Manually
The Remap task runs the command
tf workfold "$/Team Project/Project1$(Branch)" "$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)"
The Manual Get task runs the following command
get /recursive /noprompt "$/Team Project/Project1$(Branch)"
The build uses the Branch variable to point to the correct location of the solution file for the specified branch
$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)\SolutionFile.sln
The Publish Artifacts task uses the Branch variable in both the Contents field and the Path field
Example in Contents
**\$(Build.DefinitionName)$(Branch)\bin
The Label Code task uses the following command
tf label "$(build.buildNumber)" "$/Team Project/Project1$(Branch)" /recursive
The downside of this setup is that you don't capture Associated Changes and Work Items to your subsidiary branches as the Server Path field is always set to the main location. This may not be an issue if you always merge from your branches to your main location prior to launching a build meant to go to production. What you can do to compensate for this really depends on your use case.
With some tweaking, you could use this same format to specify full paths as well if you needed to.
It's impossible. Just as the error message mentioned: there are two '$' characters in the mapping. Which means your application's path shouldn't vary from build to build.
Mappings on the Repository page are used to specify source control
folder which contains projects that need to be built in the build
definition. You can set it via clicking the Ellipsis (...) button,
however, you can't include variables in the mapping path.
There is a similar question: Variables in TFS Mappings on Visual Studio Online Team Builds
So I am running into an issue when I go to build my projects using tfs build controller using the Output location "AsConfigred" it will not detect my unit tests. Let me give a little info on my setup.
TFS 2013 Update 2, Default Process Template
Here is a few screenshots that can hopefully help fill in what I can't in typing. I am copying my build out to a file share on our network so that we can use other utilities use the output. I don't want to use "PerProject" or "SingleFolder" because they mess up the file structure we have configured (These both will run the tests). So i have the files copy to folder names "SingleOutputFolder" which is a child of the DropLocation. I would like to be able to run from the drop folder or run from the bin folder for each of my tests (I don't care which). However it doesn't seem to detect/run ANY of the tests. Any help would be greatly appreciated. Please let me know if you need any additional information.
I have tried using ***test*.dll, Install\SingleFolderOutput**.test.dll, and $(TF_BUILD_DROPLOCATION)\Install\SingleFolderOutput*test*.dll
But I am not sure what variables are available and understand where the scope of its execution is.
Given that you're using Build Output location set to AsConfigured you have to change the default values of the Test sources spec setting to allow build to find the test libraries in the bin folders. Here's an example.
If the full path to the unit test libraries is:
E:\Builds\7\<TFS Team Project>\<Build Definition>\src\<Unit Test Project>\bin\Release\*test*.dll
use
..\src\*UnitTest*\bin\*\*test*.dll;
This question was asked on MSDN forums here.
MSDN Forums Suggested Workaround
The suggested workaround in the accepted answer (as of 8 a.m. on June 20) is to specify the full path to the test projects' binary folders: For example:
C:\Builds\{agentId}\{teamProjectName}\{buildDefinitionName}\src\{solutionName}\{testProjectName}\bin*\Debug\*test*.dll*
which really should have been shown as
{agentWorkingFolder}\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
However this approach is very brittle, for the following reasons:
Any new test projects you add to the solution will not be executed until you add them to the build definition's list of test sources:
It will break under any of the following circumstances:
the build definition is renamed
the working folder in build agent properties is modified
you have multiple build agents, and a different agent than the one you specified in {id} runs the build
Improved Workaround
My workaround mitigates the issues listed in #2 (can't do anything about #1).
In the path specified above, replace the initial part:
{agentWorkingFolder}
with
..
so you have
..\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
This works because the internal working directory is apparently the \binaries\ folder that is a sibling of the \src\ folder. Navigating up to the parent folder (whatever it is named, we don't care) and back in to \src\ before specifying the path to the test projects binaries does the trick.
Note: If you have multiple test projects, you add additional entries, separated with semicolons:
..\src\{relativePathToTestProjectONEBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTWOBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTHREEBinariesFolder}\*test*.dll;
What I ended up doing was adding a post build event to copy all of the test.dll into the staging location folder in the specific build that is basically equivalent to where it would go on a SingleFolder build and do that on each test project.
if "$(TeamBuildOutDir)" == "" (
echo "Building Interactively not in TFS"
) else (
echo "Building in TFS"
xcopy "$(TargetDir)*.*" "$(TeamBuildBinaries)\" /Y /E /S
)
MSBUILD parameter in the build def that told it to basically drop in the folder that TFS looks for them.
/p:TeamBuildBinaries="$(TF_BUILD_BINARIESDIRECTORY)"
Kept the default Test assembly file specification:
**\*test*.dll
View this link for the information on the variable that I used and what relative path it exists at.
Another solution is to do the reverse.
Leave all of the files in the root so that all of the built in functionality works. There is more than just test execution in there. What about static code analysis, impact analysis..among others. You would have to do something custom for them all.
Instead use a pre-drop powershell script to create your Install arrangement from the root files.
If it is an application then you can use the _ApplicationFolder Nuget package to create an _PublishApplications folder same as you get for web applications.
The C++ project I'm working on (which I converted from VS2008 to VS2010) used to use several vcbuild .rules files to specify custom build rules. These .rules files had a specific "AdditionalDependencies" property for the CustomBuildRule node which specified a list of files that the should be taken into account when working out if the target needs rebuilding or not. These "AdditionalDependencies" were faithfully carried over into the corresponding .props file during the VS2010 conversion.
The .targets file associated with the custom build rule does add these AdditionalDependencies to the Inputs property of the Target node. This ensures that the target gets executed in case any of the files listed in the dependencies doesn't exist, but it does not execute the target if one of the dependencies is newer than the target's output. It's also not quite logically correct as not all of the files are actually inputs, several of them refer to executables that might be used during the target's build. As such, they might be checked into version control and will be present, but a newer version of the file needs to trigger a rebuild of the affected target.
The MSDN documentation for the Target node shows a Condition property which should work fine for my requirements, but the conditions supported by this property don't appear go past the 'Exists' test that is already being performed.
Is there a condition that I can use which will compare two files' time stamps (or ideally, the time stamp of the files currently listed in AdditionalDependencies against the Target's output files) and thus allow me to trigger a make-like "rebuild this target if it is out of date these dependencies"?
Please take a closer look to the target Output property:
"MSBuild can compare the timestamps of the input files with the timestamps of the output files and determine whether to skip, build, or partially rebuild a target. In the following example, if any file in the #(CSFile) item list is newer than the hello.exe file, MSBuild will run the target; otherwise it will be skipped:"
<Target Name="Build"
Inputs="#(CSFile)"
Outputs="hello.exe">
<Csc
Sources="#(CSFile)"
OutputAssembly="hello.exe"/>
</Target>
The original article and more information about incremental builds with MSBuild can be found here.
How can I get Eclipse to build many binaries at a time within one project (without writing a Makefile by hand)?
I have a CGI project that results in multiple .cgi programs to be run by the web server, plus several libraries used by them. The hand-made Makefile used to build it slowly becomes unmaintainable. We use Eclipse's "Internal Build" to build all other projects and we'd prefer to use it here too, but for the good of me, I can't find how to get Eclipse to build multiple small programs as result instead of linking everything into one binary.
Solution for this described there: http://tinyguides.blogspot.ru/2013/04/multiple-binaries-in-single-eclipse-cdt.html.
There is an excerpt:
Create a managed project (File > New C++ Project > Executable)
Add the source code containing multiple main() functions
Go to Project > Properties > C/C++ General > Path & Symbols > Manage Configurations
Make a build configuration for each executable and name it appropriately (you can clone existing configurations like Debug and Release).
From the project explorer, right click on each source file that contains a main() function > Resource Configurations > Exclude from Build and exclude all build configurations except the one that builds the executable with this main() function
All other code is included in all build configurations by default. You may need to change this depending on your application.
You can now build an executable for each main function by going to Project > Build Configurations > Set Active , Project > Build Project
Using Eclipse as your build system for production code seems like a bad idea in general. I think it's a great IDE and have used it extensively for both Java and C++ projects, but for a build system I firmly believe that Ant, make, and other dedicated build utilities are the way to go.
There are several reasons for this:
Dedicated build utilities offer the very flexibility you are looking for in generating multiple executable targets.
Ant and make support most conceivable arbitrary build process chains (though not quite all).
A dedicated build utility is likely to offer greater stability and backward-compatibility for build description file formats than an IDE tool like Eclipse. Also, I'm pretty sure that Eclipse's internal build feature is dependent on the ".project" file description, and the latter's format is probably not as stable as the build description format for either Ant or make.
General-purpose, basic build utilities are usually command-line-based, which makes it easy to integrate them with more sophisticated, higher-level build utilities for automated build management like Pulse, CruiseControl, etc.
The need that is motivating your question is telling you that it's time to make the switch to a better build tool.
There is a way to use buildconfigurations to create one binary (or shared library, in my case) from each build config. Using the answer above, this means to manually exclude all but the effective main file from each build config.
I just used the above answers to ease up working on my eclipse project that creates 14 shared libraries through 14 build configs. However, configuring the indivdual "exclude from build" setting was quite cumbersome, so I switched to using the following code relying on a preprocessor-directive as my complete main file:
/*
*main.cpp
*/
/* Within
* Project | Properties | C/C++-Build | Settings
* | GCC C++ Compiler | Preprocessor
* set the following defined Symbol:
* _FILENAME=${ConfigName}
*/
#define __QUOT2__(x) #x
#define __QUOT1__(x) __QUOT2__(x)
#include __QUOT1__(_FILENAME.cpp)
#undef __QUOT1__
#undef __QUOT2__
/* The above include directive will include the file ${CfgName}.cpp,
* wherein ${CfgName} is the name of the build configuration currently
* active in the project.
*
* When right clicking in
* Project Tree | (Project)
* and selecting
* Build Configuration | Build all
* this file will include the corresponding .cpp file named after the
* build config and thereby effectively take that file as a main file.
*
* Remember to exclude ALL ${CfgName}.cpp files from ALL build configurations.
*/
Note that it does nothing else then include another .cpp file which's name is deduced from the preprocessor and a symbol that is set in the compiler options. The symbol is ${CfgName} and will be replaced by the current config name by eclipse automatically.
One does not need to configure, which file is included in which build config. Just exclude all ${CfgName}.cpp files in every build and include main.cpp in every build.
PS: the answer from hovercraft gave me the idea to have a main file that does not contain code on its own. If one includes shared code from the different effective main files ${CfgName}.cpp, working on their code may become infeasible because header files in main.cpp will not be visible in them.
I did this until yesterday, but maintaining the code with broken index etc. was a big pain.
PPS: this procedure currently breaks the automatic rebuild of the main file if only the included .cpp file was changed. It seems that eclipse does not recognize the changes in ${CfgName}.cpp (which is excluded from build). So a manual rebuild is required after every change. This is currently bugging me ;)