I have two separate projects from two separate TFS VCS roots that I want to be part of the same build and was wondering if this is possible.
Project 1
VCS Root: $/ProductName/Development/Project1
Build file path: API/API.sln
Project 2:
VCS Root: $/QA/Test/Tools/Project2
Build file path: Test/Test.sln
I want step #1 of the build to compile Project 1, and step #2 to compile Project 2. How can I do this if the build file path is relative to the VCS root/checkout directory and the solutions are from two different VCS roots?
Thanks in advance!
it is possible to have two VCS Roots and change the checkout folder of them (so not check out both in the root folder). For that, change the "Checkout Rule" on our "VCS Roots" dialog and add for your project:
For Project1:
+:.=>project1
And for Project2:
+:.=>project2
Than you get this structure in the root:
root
- project1
- project2
Related
I am trying to think through how to design a new project build system.
I want to use CMake to compile for Windows and Linux. I want to have Release and Debug builds, which are pretty straight forward.
The problem is that I will want to deploy this software for multiple hardware projects over the course of the next few years. This means that I will have pre-processor definitions to turn on/off and or alter functionality in my C++ program. I will also want to link configuration specific libraries. A current legacy project uses a header with a list of defines and then links all possible project dependencies.
An example header:
// projects.h
//#define project1
//#define project2
#define project3
Which means that to change hardware/project configurations you have to edit this file to make sure the correct hardware configuration is selected.
What I want to do is to have a configuration for each project which can also be configured for Release or Debug build.
Is there any advice on how to more optimally deal with this in CMake?
for multiple hardware projects
For me it got messy and got messy real quick.
My goals were:
I don't like a single big config.h file. I don't want to have to recompile 100% of files because I added a space in a central config.h file
All boards expose an API that user application can use. Boards don't mix together.
I can easy add new boards and have a board to test the application.
What I discovered is that:
cmake is used to configure your project for different configurations. So cmake does not store a configuration, it is used to choose a configuration.
So you need "external" place to store the configurations for current project
I have multiple applications and multiple boards, the chosen application configuration options are stored inside a makefile. This makefile then configures cmake, which in turn configures the build system, that can then be used to build the application. This is so, because cmake supports one configuration per toolchain. So for architectures with different compilers/compiler options I have to re-run cmake.
I have basically such a directory structure:
- app
- CMakeLists.txt
- main.c
- lib.c
- boards # this is actually git submodule shared between multiple projects
- boardapi # generic board api library
- CMakeLists.txt
- uart_api.h # exposes an api to access uart
- spi_api.h
- timer_api.h
- board_api.h
- some_defines.h # includes some_defines_impl.h
- BOARD1
- toolchain.cmake
- CMakeLists.txt
- implementation1.c
- implementation2.c
- some_defines_impl.h
- BOARD2
- toolchain.cmake
- CMakeLists.txt
- implementation1.c
- implementation2.c
- some_defines_impl.h
- linux
- ... as above ...
- armv5te
- ... as above ...
- CMakeLists.txt
- CMakeLists.txt
- Makefile
I have a boards directory with multiple folders per one board.
Each folder has it's own toolchain.cmake file and CMakeLists.txt file
In each CMakeLists.txt in the board folder a library with the name of the folder is added.
I have a makefile that iterates for all the boards I want to compile this application for and runs cmake + make for each of the boards. Basically BOARDS=BOARD1 BOARD2 and then all: $(foreach board,$(BOARDS),cmake;make;)
cmake is configured with cmake -DCMAKE_TOOLCHAIN_FILE=board/$(BOARD)/toolchain.cmake -DBOARD=$(BOARD)
The board/CMakeLists.txt file all does is add_subdirectory(${BOARD}) and add_library(board INTERFACE ${BOARD}).
The main CMakeLists.txt does add_subdirectory(boards) and after that link_libraries(boards). That should link all libraries with the board library.
Each board directory in turn controls the specific board configuration.
If you have multiple project configurations, just act as if they were normal projects and don't care about board. Example: iterate over them inside app/CMakeLists.txt, like so:
foreach(i IN LISTS project1 project2 project3)
add_executable(main+${i} main.c app.c)
target_add_definitions(${i})
endforeach()
Alternatively, if ex. there are many macros, you could create another structure projects/{project1,project2,project3} and recreate the same structure as for boards, but without the toolchain.cmake file. Then just iterate foreach project and do target_link_libraries(main+${i} ${i}) that will effectively bring all the macro definitions to main application.
Suppose I have the next projects structure (to be more convient let assume that QtCreator is used as IDE):
|
|-build_minGW
|-build_msvs
|-...
|-Project
|-src
|-inc
|-...
Moreover, suppose I want to use some .json files to store settings of my program. So after every compilation program should be run from the respective 'build' folder. Where should I create this .json files (Project folder, 'build' folder or elsewhere)? Is it any common and correct way to do this automaticaly (e.g. if I create files in Project folder, they should be copied to the every build directory)?
I'm using Visual Studio 2017 and the premake 5 programs.
To generate my projects I have my workspace in my premake5.lua file.
Becose my project is referencing other projects from older solutions, I can just include those basicaly with there own premake5.lua file to generate that specific project, for example shown here. As you can see, the whole source code and premake5.lua is in included as a github submodule into my current solution, so I cannot change that premake5.lua file.
The solutions premake5.lua file looks like:
workspace WorkSpaceName
...
-- glfw project
include "git submodule premake5.lua filename"
-- main project
project MainProjectName
links
{
"GLFW",
...
}
...
As of now, inside VisualStudio I got a file structure like
Solution
- Main project (with premake5.lua file)
- glfw project (github submodule, with own premake5.lua)
- ... (other projects in solution)
My question: Can I move the project glfw inside a solution subfolder from inside the premake5.lua file in the main project without touching the file from the git submodule? Then my file structure would look like:
Solution
- Main project (with premake5.lua file)
- <FolderName>
- glfw project (github submodule, with own premake5.lua)
- ... (other projects in solution/<FolderName>)
- ... (other projects in solution)
Kind regards
I found my own solution afther 2 long hours of searching:
By adding the projects to a group, they appear in a virtual folder.
group "Dependecies"
include "git submodule premake5.lua filename"
group "" -- end of "Dependensies"
From Gradle User Guide we can read that
You can use the -b option to select another build file. If you use -b option then settings.gradle file is not used.
So lets have:
-Example #Project root
--src
--main
--test
--build.gradle
--second.gradle #Second build script
--settings.gradle
What is the purpose of this? If I want to try something different with my multiproject build I create another script file - second.gradle and put it in the same directory. But want old settings.gradle file to include my subprojects.
If I execute my gradle comands when I am in the root directory of Example project for ex:
gradle -b second.gradle clean build
Why Gradle does not use settings.gradle file? To protect itself when specified build file is not in the same dir, because Gradle will looks for settings.gradle in the direcotry of build.gradle file and after that in the parent directory. But they can empty or can be from another project?
-b allows to pass a different build script for a single-project build. It is not meant to be used for multi-project builds, where settings.gradle alone determines where build scripts are located.
I am using gradle 1.4, and renamed a build.gradle to buildExpr.gradle and settings.gradle to settingExpr.gradle, both files are in the project root, and I am using following command to run gradle build.
'gradle C:\myProject>gradle -i -b buildExpr.gradle -c settingsExpr.gradle project'
it seems command line option '-c' is not being honored and gradle is not picking settingsExpr.gradle file, hence it is not able to display all modules defined in settings.gradle file while executing project task.
I am getting following log
-------------------------------------LOG----------------------------------------------------
C:\ASM\asm_workspace\asm71\AutoLab>gradle -i -c settingsExpr.gradle -b buildExpr.gradle project
Starting Build
Settings evaluated using empty settings script.
Projects loaded. Root project using build file 'C:\ASM\asm_workspace\asm71\AutoLab\buildExpr.gradle'.
Included projects: [root project 'AutoLab']
Evaluating root project 'AutoLab' using build file 'C:\ASM\asm_workspace\asm71\AutoLab\buildExpr.gradle'.
All projects evaluated.
Selected primary task 'projects'
Tasks to be executed: [task ':projects']
:projects
Root project
Root project 'AutoLab'
No sub-projects
it is very strange behavior by gradle command line shows. but if I change buildExpr.gradle to build.gradle and settingsExpr.gradle to settings.gradle, it executes normally and shows all sub-modules in log
-b and -c can't be used together. When using a settings file, everything else (e.g. the locations of build files) is determined from the settings file.