We have our own GCC based compiler. We use eclipse in order to develop .c files using our compiler – after hitting the build button eclipse manages to run our ‘make’ file and the build operation succeeds.
We’re trying to configure the eclipse project such that it will use this compiler in order to show the compilation errors as red underline marks during the code-writing stage.
In order to do so, we add the following configurations:
Project properties > C/C++ Build>Tool chain editor > current toolchain: “Cross GCC”, current builder: “CDT internal builder”
Project properties > C/C++ Build>Settings>Tool Settings>Cross Settings> - here I set the prefix and the path of my GCC compiler.
Project properties > C/C++ General > Preprocessor include path, Macro etc. > providers > check: “CDT Cross Build Output Parser” and inside check “Allocate console in the console view”.
After doing that we get the following error in the console view:
i486-elf-g++ -E -P -v -dD
C:/Users/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Cannot run program "i486-elf-g++": Launching failed Error: Program
"i486-elf-g++" not found in PATH
It looks like eclipse is trying to compile a file named “spec.C”, in the plugin directory. We tried to look for that file and we only found an auto-generated file called “spec.c” (lower case .c) that is empty.
Our compiler executable name is “i486-elf-gcc”.
What additional steps need to be done?
Note that running the make file using the “build” button completes without errors or warnings.
Thanks
This is not related to the spec.c. It seems that the path of the i486-elf-gcc is not in the PATH variable. You can add the path the PATH-varaible in the "Environment" -tab
Related
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.
I am trying to learn jdb. I have a maven project. I tried debugging it with jdb when I use the list command I am not able to see any source code. I get this message:
main[1] list
Source file not found: App.java
So how should I compile a project with maven so that it can latter be debugged with jdb and I can see the source code?
Looks like this has nothing to do with maven. One of the options jdb takes is the sourcepath and it is over here you specify the path(s) it will search for the source code.
I'm trying to use sonar for static analysis on a c++ code. I've installed sonar and configured my project (it appears on the localhost sonar page, but i do not see any code violation for the respective code). I have the C++ community plugin installed.
My sonar-project.properties looks like this:
# required metadata
sonar.projectKey=DiceInvaders
sonar.projectName=Dice Invaders
sonar.projectVersion=1.0
# optional description
sonar.projectDescription=DiceInvaders by CS
# path to source directories (required)
sonar.sources=D:\\DiceInvaders\\Code
# path to test source directories (optional)
#sonar.tests=D:\\DiceInvaders\\Code
# path to project binaries (optional), for example directory of Java bytecode
#sonar.binaries=binDir
# optional comma-separated list of paths to libraries. Only path to JAR file is supported.
#sonar.libraries=path/to/library/*.jar,path/to/specific/library/myLibrary.jar,parent/*/*.jar
# The value of the property must be the key of the language.
sonar.language=c++
sonar.exclusions=**/*.ipch, **/**/*.rc
sonar.cxx.cppcheck.path = "C:\Program Files (x86)\Cppcheck\cppcheck.exe"
sonar.cxx.cppcheck.reportPath="D:\DiceInvaders\Code\cppcheck-reports\cppcheck.xml".
# Additional parameters
#sonar.my.property=value
I do not get any error when running sonar-runner from cmd.
If i run manually the cppcheck.exe tool on my project I can find violations. Why don't the violations appear on sonar's page?
Is there something else I should configure, am I doing something wrong?
I was able to make it work by running the cppcheck tool independently before sonnar-runner, and placing the generated xml report in the bin folder of sonnar-runner.
In the sonar-project.properties file I've specified the xml directly:
sonar.cxx.cppcheck.reportPath=cppcheck-result-1.xml
I had a similar problem, which was caused by a whitespace after 'sonar.language=cs'. Be sure that there is a linebreak immediately after 'cxx'. Hope it works.
The language key of the Sonar C++ Community plugin is not 'c++' but 'cxx'. See http://docs.codehaus.org/pages/viewpage.action?pageId=185073817.
So you must replace 'sonar.language=c++' by 'sonar.language=cxx'
I have an Xcode project with a large number of targets where I would like to include a settings bundle for apps built under the Ad-hoc and Debug configurations, but not under the Release configuration.
Build Phases don't seem to allow for making themselves conditional on configuration (they can obviously be conditional on target, but doubling the number of targets in the project would make it completely unusable).
That leaves writing a custom Build Rule. My plan is to exclude the Settings.bundle from all targets, and create a build rule that conditionally copies it into the product package, but applicable examples are really hard to find.
The build rule I've started has the Process setting set to "Source files with names matching:" and Settings.bundle as the name. The Using setting is "Custom script:".
My custom script is as follows (with the caveat that my bash scripting is on a cargo cult level):
if [${CONFIGURATION} = 'Debug'] then
cp -r ${INPUT_FILE_PATH} ${DERIVED_FILES_DIR}/.
fi
Finally, I have ${DERIVED_FILES_DIR}/Settings.bundle listed as an output file.
Since I'm here, it should be obvious that it's not working. My first question is whether there is somewhere I can view the output of the build rules as the execute to make sure that 1) it's actually being executed and that 2) I don't have a stupid syntax error somewhere.
Also, what's the proper location (in the form of an environment variable) to copy the output to?
I finally figured it out.
For each target for which you want to conditionally include the settings bundle, choose its Project from the source list, choose the target, and switch to the "Build Phases" tab.
Click the "Add Build Phase" button and choose "Add Run Script".
Then enter the following for the script:
if [ "${CONFIGURATION}" == "Debug" ]; then
cp -r "${PROJECT_DIR}/Settings.bundle" "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app"
fi
I know this question has been answered already, and the answer was very helpful to me, but I wanted to throw my own modified solution out there as well.
My requirement was to have different settings bundles for different build configurations, rather than just not including it at release. Assuming a simplistic approach of only Debug and Release configurations, here's how to do it:
Start by adding 2 settings bundles to the project, named Settings-debug.bundle and Settings-release.bundle and then remove these files from the Copy Bundle Resources build phase. Next add a user defined build setting called SETTINGS_BUNDLE, which has different values for each configuration:
Debug ${PROJECT_DIR}/relative/path/to/Settings-debug.bundle
Release ${PROJECT_DIR}/relative/path/to/Settings-release.bundle
Next add a run-script build phase (after Copy Bundle Resources) named Copy Settings Bundle with a modified version of the script in Frank's solution.
cp -r "${SETTINGS_BUNDLE}/" "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Settings.bundle"
The difference here is that the copied bundle is always named Settings.bundle regardless of the source name.
You then need to add another build phase script to prevent code signing errors when the only changes are in the settings bundles. It forces the code signing step to occur on every build. This should run before the Compile Source Files build phase. I called mine Force Codesign.
touch "${PROJECT_DIR}/relative/path/to/main.m"
For complied sources, there is a poorly documented user defined build setting that can be added. Files can be both excluded and included from compilation
Go to your target's Build Settings > Tap the + button > Add User-Defined Setting
The key is either INCLUDED_SOURCE_FILE_NAMES or EXCLUDED_SOURCE_FILE_NAMES
The value is a space separated list of file paths
See reference:
http://lists.apple.com/archives/xcode-users/2009/Jun/msg00153.html
(Tested with Xcode 9.3)
I can't find when Xcode included this feature but EXCLUDED_SOURCE_FILE_NAMES is now directly available in Build Settings > Build Options > Excluded Source File Names.
So you no longer need to create a User-Defined Setting.
See below:
It will automatically add this line in your .pbxproj.
Settings.bundle is always copied into destination area no matter whether Release or Debug configuration. So, maybe you need the following code:
if [ ${CONFIGURATION} == "Release" ]; then
rm -rf ${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Settings.bundle
fi
I am no shell script expert but I think you need space between the square brackets and the condition. Also, quoting the variables may help:
if [ "${CONFIGURATION}" = "Debug" ] then
cp -r "${INPUT_FILE_PATH}" "${DERIVED_FILES_DIR}"/.
fi
As for the location, I use "$BUILT_PRODUCTS_DIR"/"$FULL_PRODUCT_NAME" for the root of my OS X app bundle.
What I did:
I have a script that
Read some configuration files to generate source code snippets
Find relevant Objective-C source files and
Replace some portions of the source code with the generated code in step 1.
and a Makefile that has a special timestamp file as a make target and the configuration files as target sources:
SRC = $(shell find ../config -iname "*.txt")
STAMP = $(PROJECT_TEMP_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME).stamp
$(STAMP): $(SRC)
python inject.py
touch $(STAMP)
I added this Makefile as a "Run Script Build Phase" on top of the stack of build phases for the project target.
What happened:
The script build phase was run before compiling the source.
However, since the script modifies source code during its execution, I needed to build twice to get the most recent version of the build product. Here is what I imagine to be happening:
1st run: Xcode collects dependency information ---> no changes
1st run: Xcode runs "Run Script Build Phase" ---> source is changed behind Xcode's back
1st run: Xcode finishes build, thinking nothing needs to be updated
2nd run: Xcode collects dependency information ---> source has changed, needs rebuild!
2nd run: Xcode runs Run Script Build Phase" ---> everything is up-to-date
2nd run: Xcode proceeds to compilation
After reading Xcode documentation on Build Phases, I tried adding a source file which is known to be updated every time the script is run as the output of "Run Script Build Phases", but nothing changed. Since the number of configuration files may vary in my project, I don't want to specify every input and output file.
Question:
How do I make Xcode aware of source file changes made during "Run Script Build Phase"?
Edit:
Added that I placed the script build phase before the other build phases
Every technique mentioned so far is an overkill. Reproducing steve kim's comment for visibility:
In the build phases tab, simply drag the "Run Script" step to a higher location (e.g. before "Compile Sources").
Tested on Xcode 6
This solution is probably outdated. See the higher voted answer instead; I no longer actively use Xcode and am not qualified to vet a solution.
Use "External Target":
Select "Project" > "New Target..." from the menu
Select "Mac OS X" > "Other" > "External Target" and add it to your project
Open its settings and fill in your script setup
Open the "General" tab of the main target's settings and add the new target as it's direct dependency
Now the new "External Target" runs before the main target even starts gathering dependency information, so that any changes made during the script execution should be included in the build.
There is another, slightly simpler option that doesn't require a separate target, but it's only viable if your script tends to modify the same source files every time.
First, here's a brief explanation for anyone who's confused about why Xcode sometimes requires you to build twice (or do a clean build) to see certain changes reflected in your target app. Xcode compiles a source file if the object file it produces is missing, or if the object file's last-modified date is earlier than the source file's last-modified date was at the beginning of the first build phase. If your project runs a script that modifies a source file in a pre-compilation build phase, Xcode won't notice that the source file's last-modified date has changed, so it won't bother to recompile it. It's only when you build the project a second time that Xcode will notice the date change and recompile the file.
Here's a simple solution if your script happens to modify the same source files every time. Just add a Run Script build phase at the end of your build process like this:
touch Classes/FirstModifiedFile.m Classes/SecondModifiedFile.m
exit $?
Running touch on these source files at the end of your build process guarantees that they will always have a later last-modified date than their object files, so Xcode will recompile them every time.
As of Xcode 4, it looks like if you add the generated files to the output section of the build phase, it will respect that setting, and not generate the ... has been modified since the precompiled header was built error messages.
This is a good option if your script is only generating a handful of files each time.
I as well struggled with this for a long time. The answer is to use ento's "External Target" solution. He is WHY this problem occurs and how we use it in practice...
Xcode 4 build steps do not execute until AFTER the plist has been compiled. This is silly, of course, because it means that any pre-build steps that modify the plist won't take effect. But if you think about it, they actually DO take effect...on the NEXT build. That's why some people have talked about "caching" of plist values or "I have to do 2 builds to make it work." What happens is the plist is built, then your script runs. Next time you build, the plist builds using your modified files, hence the second build.
ento's solution is the one way I've found to actually do a true pre-build step. Unfortunately I also found that it does not cause the plist to update without a clean build and I fixed that. Here is how we have data-driven user values in the plist:
Add an External Build System project that points to a python script and passes some arguments
Add user-defined build settings to the build. These are the arguments that you pass to python (more on why we do this later)
The python script reads some input JSON files and builds a plist preprocessor header file AND touches the main app plist
The main project has "preprocess plist files" turned on and points to this preprocessor file
Using touch on the main app plist file causes the main target to generate the plist every time. The reason we pass in build settings as parameters is so our command-line build can override settings:
Add a user-defined variable "foo" to the prebuild project.
In your prebuild you can use $(foo) to pass the value into the python script.
On the command-line you can add foo=test to pass in a new value.
The python script uses base settings files and allows for user-defined settings files to override the defaults. You make a change and immediately it ends up in the plist. We only use this for settings that MUST be in the plist. For anything else it's a waste of effort....generate a json file or something similar instead and load it at run-time :)
I hope this helps...it's been a couple rough days figuring this out.
The External Target solution from #ento no longer works as of Xcode 11.5. The solution is to add all files that will be changed under Output Files in the Run Script.
Another option is to create a subproject framework with your scripts and just add it as a dependency to all targets. The phase scripts of this subproject should now be executed before all targets.