Context
I have a remote server with C++ code and Makefile, and I want to use Clion's remote development + Makefile plugin to develop a Makefile project in remote.
I have mostly been following this guide from Jetbrains to set up remote development.
I have followed all the instructions:
install Makefile plugin
set up Remote Host in Build, Execution, Deployment | Toolchains ( there was no problem setting up the remote host )
create corresponding CMake profile in Build, Execution, Deployment | CMake and selected the created Remote Host in the Toolchain
set mapping to my newly created C++ Cmake project to the remote directory under Build, Execution, Deployment | Deployment | Mappings.
Problems with setup
After following all the instructions, I have two issues:
My local project and remote repository are out of sync. My local contains dummy files created on project initialization: cmake-build-debug directory, CMakeLists.txt, and main.cpp, while my remote contains code and Makefile.
There is no configuration created for me to run and build. In the top-right corner where there is run, debug and build buttons, no pre-created configuration is shown:
Instead, there is Add Configuration button. When I click Add Configuration and navigate to create new Makefile configuration, there is no option for me to set up project in remote.
Question
So my question is:
Do I need cmake-build-debug directory and CMakeLists.txt even if I am only going to use the Makefile plugin to build and run? If not, how should I sink my files with remote?
How can I create debug and run configuration with Makefile s.t. it will only build and run on the remote host I have set up?
Several things here:
Full remote mode in CLion works only with CMake projects for now.
Makefile plugin doesn't provide Makefiles project model support in CLion (and you can't work w/o a project model in CLion, the code won't be resolved), it's for syntax highlighting in such files mostly and for Makefiles run/debug configuration. To work with makefiles in CLion, you need a workaround through the compilation database. Please check here: https://www.jetbrains.com/help/clion/managing-makefile-projects.html. But again this works only for local projects.
Related
I want to trigger a Jenkins job for a maven(v3.5.3) project from my local work space folder location instead of configuring SVN Repository URL in the Source code management section. Is there a way to achieve this?. I need to test with code modifications in the project and not wanting to commit the changes, that is the purpose.
I am using Jenkins (v2.161) and it is installed in another machine.
Thanks in Advance.
Although it might look like a sort of tinkering, the source code can be pulled to the Jenknins' host from your local machine, provided that they are properly configured to communicate via ssh.
In the project build configuration on Jenkins' host:
Do not use "Source Code Management" (choose "None").
Check "Delete workspace before build starts", to avoid conflicts with previous changes.
As the very first build step, add "Execute shell" and write a few commands that pull the data, for example:
scp myusername#myhost:/path/to/myworkspace/myproject/src .
scp myusername#myhost:/path/to/myworkspace/myproject/pom.xml .
# etc for all the files/dirs you need to build the project
Then continue with the build steps that were already used for building the project from SCM.
I'm in the process of setting up a .NET Core project with Docker in Visual Studio 2017. I've created the project and added the docker-compose to the solution, and everything works.
But somehow, the VS won't build and run Docker with any configurations, other than Debug and Release.
I've created solution and project configurations named Preproduction and selected it, as well as created a docker-compose.vs.preproduction.yml file.
But when I run the preproduction configuration, the project runs as if Release was selected instead. The Build Output console also shows the following:
Debug
*docker-compose -f "docker-compose.yml" -f "docker-compose.override.yml" -f "docker-compose.vs.debug.yml" -p dockercompose3979710767*
Release
*docker-compose -f "docker-compose.yml" -f "docker-compose.override.yml" -f "docker-compose.vs.release.yml" -p dockercompose3979710767*
Preproduction
*docker-compose -f "docker-compose.yml" -f "docker-compose.override.yml" -f "docker-compose.vs.release.yml" -p dockercompose3979710767*
Notice the second yml file.
Somehow it uses the release file, and not the custom configuration file I've added.
Does anyone have any idea how to solve this, so docker will use my custom configurations?
Unfortunately it is not possible. After spending a lot of time to figure it out, it turned out that those two filenames are hardcoded into a DLL. Everything which is not 'DEBUG' will use the 'RELEASE' files.
Using different docker-compose.yml files by referencing them from different folder could be a solution, but since it is not a standard project but a Docker project, you don't have access to the post build events to copy the required files there. Furthermore you cannot have multiple Dockerfile, because it is also based on name convention.
You can use one version to develop and test, defined in the included files and create a script which builds everything manually based on your existing compose files and your extra.
I provide some non-standard solution for this issue can be solved. Here we go:
1) Get dnSPY tool (https://github.com/0xd4d/dnSpy/releases)
2) Install it
3) Find file Microsoft.Docker.dll (For me it was in "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\tools" way.)
4) Get copy of this file (copy in some directory for example).
5) Open this dll in dnSpy.exe
6)Go Microsoft.Docker (version number) -> Microsoft.Docker.dll -> DockerComposeClient class -> MergedDockerComposeDocumentProvider private class -> GetDocuments private method
7) In this method you can see all file pathes and files used for build
8) RightClick on necessary string -> Edit IL Instructions
9) Edit what you need (as for me I was able to change docker-compose.override.yml to docker-compose.development.yml)
10) Save change
11) File -> Save Module and saving your upgraded DLL.
WHOILA!!! Actually
you must restart VS and maybe docker. After this your changes will be apply to pipeline build. Enjoy
How can I make Jenkins do the following?
Checkout trunk/ from SVN, then build configurations Debug and Release using CMake, without having duplicate jobs for the configurations.
Took me a while to figure this out. Here's how I managed to do it.
Create a free-style job "Checkout". This job is going to do all the stuff that doesn't depend on the configuration type (Debug/Release).
Under "Source Code Management" select Subversion
Fill in the Repository URL. Probably a good idea to make it point to /trunk.
Set Local module dir to "." (no quotes)
As Check-out Strategy "Emulate clean" is nice
Build trigger Poll SCM, set Schedule to "5 * * * *" to check every 5 minutes.
Now under Advanced Project Options check 'Use custom workspace' and set the dir to e.g. "c:/src". We don't want Jenkins to use its internal workspace, because we want other jobs to be able to access the source.
Under Build add the following Windows batch command, which is used to clean the build dir. For some reason, CMake doesn't provide a way to do this.
cd c:\
rmdir /S /Q build
mkdir build
cd build
cmake --version
rem optionally: svn info c:\src
cmake -G "Visual Studio 10" c:\src
Create another job "Build", this time make it a "multi-configuration" job. This job is going to run for each configuration (Debug/Release).
First, set the Build Triggers to build after job "Checkout"
Now under Configuration Matrix add an axis "configuration" with values "Debug Release" (whitespace = separator). Unfortunately, the CMake builder plugin for Jenkins doesn't work with multi-configuration jobs. We can't even use cmake --build, because it always builds the Debug configuration. To build, we have to use another batch script:
cd c:\build
call "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
msbuild ALL_BUILD.vcxproj /verbosity:minimal /maxcpucount:1 /property:Configuration=%configuration%
If you want to build the entire solution, specify the .sln file instead of ALL_BUILD.vcxproj. If you only want to build a specific project, use
msbuild <solution>.sln /target:<project>
Use Jenkins Matrix job. Define one of the axes as build_mode with values Debug and Release. You then run CMake that will create both configurations for the compilation tool you'll be using (XCode, gcc, VisualStudio, etc.). You can then use build_mode as if it were an environment variable and pass it to build steps that do actual compilation.
When using the Visual Studio generator you can pass the configuration to build to the cmake --build-command:
cmake --build . --config Release
cmake --build . --config Debug
See also the CMake docs.
After using Jenkins for a while now, I found that you should use as few jobs as possible if you want to reuse the source directory.
The default setup in Jenkins is that each build uses a different directory as its workspace. Which implies that you do a complete SVN checkout every build. Which takes forever.
If you want to use the same source directory for every build, you have to worry about synchronization: Only one build at a time. As far as I know, Jenkins has no built-in means of synchronization. The only way is to only use one executor. Even then you can't control the way the executor chooses its next job.
Let's say job "SVN update" triggers job "Build". Someone starts "SVN update #33", which is supposed to trigger "Build #33". If, however, Jenkins' "Poll SCM" feature schedules "SVN update" #34 in the meantime, I haven't found a way to tell it that "Build #33" must run before "SVN update #34". So you might end up with "SVN update #34" running before "Build #33", and everything fails. Unless you manually disable the polling job. And remind yourself to re-enable it afterwards, of course.
Anyways. After using Jenkins for two years, I change my answer to: Never use multiple jobs that share resources (like the source dir), and bake all the logic into shell scripts (for loop over configurations).
I have a project that when built from my machine everything runs smoothly. However, when I push my changes and try to generate the build using jenkins, I'm getting the library not found error message.
This is weird because if I login into the jenkins server and I try to do a manual build, everything works as expected, perfect. It's only when I build from withing jenkins that my build is failing.
I'm assuming LIBRARY_NAME as the name of whatever library, in my case is an internal static library.
Any suggestions?
EDIT:
I've setup: Library Search Headers, Other Linker Flags, Target Dependencies, Proper Architectures
I wrestled with this for three weeks until I accidentally stumbled onto this with the help of a coworker. Basically, you must be sure that the path structure created in your repository is replicated in the .jenkins workspace. To do this just be sure that in your project/job configuration in jenkins the Source Code Management > Subversion > Repository URL field must be at the same level as specified in jenkins in your script or Build > Execute Shell > Command field. So here are my settings as an example:
above Jenkins URL = https://myDuncwa.local/duncwa-repo
above Jenkins Build = "cd $WORKSPACE/mobileapps/projects/PictureBoard/trunk/PictureBoard" and line 2 "xcodebuild -project PictureBoard.xcodeproj" no quotes.
above Subversion URL repository = https://myDuncwa.local/duncwa-repo
This will cause the directory structure mobileapps/projects/PictureBoard in my repository to replicated in the .jenkins/jobs/PictureBoard/workspace/mobileapps/projects/PictureBoard directory that is created automatically by jenkins. Note: 1) This will copy the entire repository so be prepared to change this later and 2) .jenkins is a hidden directory created by the install in the installing user's home directory or "~/"
I am developing an app and I am using an open source component.
I have a workspace containing both MyApp.xcodeproj and Component.xcodeproj. My app has three configurations: Debug, App Store and In House but the component has only two: Debug and Release
In the Debug configuration, everything works fine, but I can't compile my app in App Store or In House configuration because the configuration names do not match. I get a file not found error when trying to #import <Component/Component.h>
I need both App Store and In House configurations and I would really like to avoid modifying the component's configurations in order to ease future updates of the component.
I know I could use CocoaPods to solve this issue but I would like to know if there is a simple solution in Xcode
You can get your project to compile with some tweaks to your app’s settings.
I suggest you to modify all settings at the project level so that all your targets can inherit these settings.
Add a new DEFAULT_CONFIGURATION user-defined setting and define your configuration mapping. This is how it should look like:
Set FRAMEWORK_SEARCH_PATHS to $(BUILD_DIR)/$(DEFAULT_CONFIGURATION)-$(PLATFORM_NAME) for all configurations, add Any OS X SDK variants and set the value to $(BUILD_DIR)/$(DEFAULT_CONFIGURATION). Set HEADER_SEARCH_PATHS to $(FRAMEWORK_SEARCH_PATHS)/include and LIBRARY_SEARCH_PATHS to $(FRAMEWORK_SEARCH_PATHS). This is how it should look like:
This step is quite tedious, it can be automated with the xcproj tool and by running this script in your project directory. Edit your configurations mapping as needed.
#!/bin/bash
CONFIGURATIONS=( "App Store:Release" "In House:Release" "Debug:Debug" )
for CONFIGURATION in "${CONFIGURATIONS[#]}"; do
xcproj --configuration "${CONFIGURATION%%:*}" write-build-setting DEFAULT_CONFIGURATION "${CONFIGURATION#*:}"
done
xcproj write-build-setting 'FRAMEWORK_SEARCH_PATHS' '$(BUILD_DIR)/$(DEFAULT_CONFIGURATION)-$(PLATFORM_NAME)'
xcproj write-build-setting 'FRAMEWORK_SEARCH_PATHS[sdk=macosx*]' '$(BUILD_DIR)/$(DEFAULT_CONFIGURATION)'
xcproj write-build-setting 'HEADER_SEARCH_PATHS' '$(FRAMEWORK_SEARCH_PATHS)/include'
xcproj write-build-setting 'LIBRARY_SEARCH_PATHS' '$(FRAMEWORK_SEARCH_PATHS)'
If the component is distributed as a static library, you are done here. If the component comes as a framework you have to update its path reference by editing your project.pbxproj file in a text editor. In the PBXFileReference section (under /* Begin PBXFileReference section */) find Component.framework and update its path like this:
name = Component.framework; path = "../$(DEFAULT_CONFIGURATION)/Component.framework"; sourceTree = BUILT_PRODUCTS_DIR; };
Also make sure that the sourceTree is set to BUILT_PRODUCTS_DIR, i.e. relative to built products. Once you edited the project file, this should look like:
Your project should now build as expected.
I had this same problem, but I had multiple configurations (Debug, TestFlight, Release, Enterprise) in my app, and the bolded configurations would always fail to build cause it couldn't find the frameworks. I really didn't want to mess with the project settings of my sub projects in order to make updating them easy.
The answer I found was to just update the framework search path to account for the fact that the frameworks would be dropped in Release (or whatever the default configuration is set to) of the sub projects.
Specifically I set it to:
$(BUILD_DIR)/Release-$(PLATFORM_NAME)
I set it to be recursive too. This works both for Simulator and Device, building in Xcode and command line.
I solved it in the following way,
In my dependency project,
Project -> Target -> Build Phases, added new Run Script
TARGET_DIR="Build"
TARGET_FILE="${TARGET_DIR}/${FULL_PRODUCT_NAME}"
mkdir -p ${TARGET_DIR}
rm -rf ${TARGET_FILE}
cp -rf "${BUILT_PRODUCTS_DIR}/${FULL_PRODUCT_NAME}" ${TARGET_DIR}
After the every build, I copy the build to my Build directory inside the project.
And from the main project,
Project -> Target -> General, I drag and dropped the dependency Framework (which is inside dependency project's Build folder)
then,
Project -> Target -> Build Settings -> Framework Search Paths, under my custom Build Configuration, I added the following
$(PROJECT_DIR)/../DependencyProject/Build
The folder is relative to my main project, and this should be relative to your project.
Then in my all the schemes, I added a Pre-actions script for Build with
rm -Rf "${PROJECT_DIR}/../DependencyProject/Build"
Also you need to select the app against Provide build settings from drop down.