I have a remote, cross build and I would like to manually take the gcc command line from the makefile build, and use it to setup the Eclipse CDT project file with include paths and preprocessor definitions. How can I do this?
The usual way to do this is using the Build Output Parser.
Create a Makefile project
Enable the Build Output Parser in Project Properties | C/C++ General | Preprocessor Include Paths, Macros etc. | Providers tab (in might already be enabled).
Configure it if necessary (e.g. the "Compiler command pattern" may need to be adjusted to match your cross-compiler's name.)
Make sure you can build the project from within Eclipse. If necessary, configure the make target name and invocation directory in Project Properties | C/C++ Build.
Invoke the build from within Eclipse.
The Build Output Parser will run automatically at the end of the build, parse the compiler commands in the build output, and configure the project's include paths and preprocessor defines based on the commands.
Note: for this to work, the build output needs to actually contain the raw compiler commands. Sometimes, e.g. with CMake-generated makefiles, it doesn't by default but there is an option to enable it - if so, be sure that the "Build command" specified in Project Properties | C/C++Build contains that option.
Related
Let's make an example in Eclipse: I have two different source files for a Startup with a main-function, but depending on which build configuration I use, either one of them is used, or the other one.
I do this, by defining a custom symbol with the "-d" option in one of the build configurations, and leaving it out in the other one.
#ifdef CUSTOMSYMBOL
...
Specifically, under Eclipse, I can edit these settings under Project -> Properties -> C/C++ Build -> Settings -> Cygwin C++ Compiler -> Prepocessor
(I am using Cygwin under Windows for my C++ projects)
This works. Depending on which build configuration I use, only one of the two source files will be built by the compiler and the other one will be ignored.
However, this setting is specific to Cygwin.
I can't figure out, how to do it in QNX Momentics, since I do not have those options under the qcc Compiler.
You can do this in the Compiler Tab of your QNX C/C++ Project as shown below:
After importing a c++ Makefile-project into Eclipse, my project depends on some libraries which are located in /usr/include/gazebo-2.2/gazebo.
These are included via the line #include < gazebo/xx/xx.hh>. CMake doesn't have a problem finding the files, Eclipse unfortunately does...
In my include folder, the folder /usr/include/ is set as include path. However it can't find the include files.
Is it possible for eclipse to discover the files without adding the full path to the include directories?
Is it possible for eclipse to discover the files without adding the full path to the include directories?
Since you are using a Makefile project, presumably your makefile specifies the relevant include path. Eclipse can pick this up using its Build Output Parser. The general way to set this up is:
Make sure your makefile can produce output that includes the full compiler command invocations (e.g. gcc -I /usr/include/gazebo-2.2 ... - since this is what the build output parser needs to see), or can be configured to produce that output.
Make sure Eclipse is configured to invoke your makefile correctly (in terms of invocation directory and target name) in Project Properties -> C/C++ Build.
Make sure the build output parser is enabled in Project Properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers tab. If necessary, adjust the "Compiler command pattern" as appropriate.
Perform a build from within Eclipse. Assuming your build is successful (or at least succesful enough for the build output to contain the compiler commands for every source file), the build output parser should then pick up information such as include paths and macros defined on the command line. In the Project Explorer, source files for which settings were picked up in this way will be annotated with a little wrench decoration on the icon.
At this point, your includes should be resolved. You may need to re-build the index to get Eclipse to process the contents of the newly resolved files.
For completeness, since you mentioned CMake, I'll mention that there also exist plugins that will configure a project's include paths directly based on CMakeLists.txt. (I can't recommend a specific one because I don't use CMake myself, but searching for "CMake" in the Eclipse Marketplace should give you several options.)
Is it possible for eclipse to discover the files without adding the full path to the include directories?
No, not unless the include path in question is one of the compiler's default include
paths, which is not so in your case.
If your want the compiler to find the header file referred to by e.g.
<gazebo/xx/xx.hh>
when the required file is:
/usr/include/gazebo-2.2/gazebo/xx/xx.h
then the compiler must be given the include path:
/usr/include/gazebo-2.2
which should appear in compiler commandlines in your build log as:
-I/usr/include/gazebo-2.2
I notice also that your example is actually:
#include < gazebo/xx/xx.hh>
not:
#include <gazebo/xx/xx.hh>
In your example, the leading space will be considered part of the
filename and the header would not be found.
I would love to import a Makefile project from Eclipse, and have all the different includes path that the compiler uses to create correctly my Eclipse project.
Unfortunately, those path, specified on the command line by a "-I" don't show up in Project Explorer and I have to add them by hand.
I am currently importing the project using the standard "Import project from Makefile" built in Eclipse.
If I'm not wrong there was an autodiscovery option in older versions of Eclipse, but it's not there anymore.
How do you do for having all your include paths set up without too much hassle?
The trick is NOT to use
File->New->Makefile Project with Existing Code
but to use
File->New->C++ Project
and then to select
Makefile project->Empty project.
After you set up such a dummy project, you simply copy your existing source to that project directory, hit F5 (i.e. Refresh) and change the build command to use your Makefile.
I was able to get this to work using Luna. I imported using File->New->C++->Makefile Project with Existing Code.
Prior to launching eclipse, you have to be sure to source any files that set required environment variables.
I did have some build options which were not the standard all and clean, so I had to add those configurations individually.
source files to setup your environment.
Launch Eclipse
Import C++ Makefile project
Setup Build options.
Click the hammer.
In my scenario I have a C++ project in CDT Eclipse. This projects however is rather a collection of individual (helper) programs than one complex application. Consequently I want to be able to build and run them individually.
My project structure is very simple and looks like:
src/app1.cpp
src/app2.cpp
src/...
Note that I do not have common header files or libraries. However I want to be able to add programs to this project just by creating e.g. src/appx.cpp
Ideally I want to have shortcuts for
"Build currently opened .cpp"
"Run binary of currently opened .cpp"
Any suggestions on how to achieve this behaviour, if possible without additional plugins?
The straightforward way to succeed what you aim is to create a Makefile project with CDT and add a new target rule for each of your applications inside your Makefile. You can even use SCons or other build systems with a CDT Makefile project and obtain the same effect.
You can also trick the managed build to create executables instead of object files. Remove -c option from Other flags of C++ compiler settings inside project properties. This will produce a separate application file for each of your source files.
Application files which are created inside the build directory will have the object file extension and they will not be executable. To solve this, you can add a post build script in your project directory such as:
postbuild.sh for Linux:
chmod +x *.o
rename -v 's/\.o$//' *.o
or postbuild.bat for Windows:
rename *.o *.exe
After adding ../postbuild.sh or ../postbuild.bat as a post build command in your build settings, you applications will be ready to run. Right click on any of these executable files and choose Debug As or Run As and a new Run configuration will be created.
Also you will have to stop the linker of the managed build to prevent errors. This can be achieved with changing the linker command to true (Linux) or true.exe (Windows, msys).
I have a program which consists of multiple projects in eclipse (working under ubuntu and the projects being in c++), these projects consist of a main executable file, and other shared objects files and static libs.
I want all these projects when built to output their files to one common binary folder, instead of their respective debug folders. This is to make linking easier with the main executable. If there are better solutions please also feel free to share.
Unfortunately, I have found that the C/C++ Build tab does not allow you to set the build location unless you are creating your own makefile.
You've likely found that the Builder Settings tab under Project Properties>C/C++ Build is all grayed out in a default C/C++ project. This is because CDT nominates the internal builder by default for new projects. To change this, you can go to Project Properties>C/C++ Build>Tool Chain Editor and change the Current Builder to Gnu Make Builder. Next, go to Project Properties>C/C++ Build and change the Builder Type to External Builder. You can now opt to create your own makefile for the project, if you like; though I'd recommend leaving CDT to build the makefile automatically for now.
I have the same project requirements of outputting to a /project_path/bin (though I still maintain separation between Debug and Release builds). To do this, I perform a copy operation on the output as a post-build step.
To do this, go to Project Properties>C/C++ Build>Settings and select the Build Steps tab. In the Post-build steps under Command:, enter:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "/path/to/bin/directory/";
Obviously replacing the "/path/to/bin/directory/" as required.
I personally prefer to maintain my project files in a workspace/build directory; copying binaries to a workspace/bin directory and libraries to a workspace/lib directory. At first I found this copy workaround to be an inconvenience, but have come to appreciate it because it isolates the interstitial build files from the final binary/library.
For binaries, I would use:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "${WorkspaceDirPath}/bin/";
For libraries, I would use:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "${WorkspaceDirPath}/lib/";
I include the variable "${BuildArtifactFilePrefix}" because CDT includes "lib" as a default prefix for static libraries, which I actually prefer.
You just need to ensure that the target directory exists before building; Eclipse/CDT will not create the directory for you.
Also, just remember that these copies will be left behind in the /bin or /lib directory on clean, but overwritten on any subsequent rebuild.
Try Project->Properties
Under C/C++ Build->Settings you have a tab called Build Artifact.
Under there you have Artifact name. This defaults as ${ProjName}.
Modify this to specify a relative directory path to where you actually want the final file to end up. So could be ../../lib/${ProjName}
The intermediate files (.o and .d) will still build to the sub-directory (Debug or Release) but I guess it's better off if they are there anyway and it is only the finally built library for which you want to change the build path.
If you find it inconvenient typing the relative path like this, I use Environment to create environment variables with relative paths taking me back to a "root". One of this I have is ${LIBDIR} and this is a relative path from where the project gets built. It is usually used for linking in other libraries, but can also be used as a target. Then you would set Artifact Name to ${LIBDIR}/${ProjName} which works well if you use different directories for debug and release builds.
Go to
Project Properties -> C/C++ Build -> Settings -> (tab) GCC C++ Linker
The command line pattern is shown on the right side
${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX} ${OUTPUT} ${INPUTS}
Put in front of ${OUTPUT}
${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX} ${ProjDirPath}/bin/${OUTPUT} ${INPUTS}
or
${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX} MyMainProject/path/bin/ ${INPUTS}
From https://www.eclipse.org/forums/index.php?t=msg&th=207500&goto=665566&#msg_665566
In my project the build path defaults to the Build Configuration name, so I could use a ${ConfigName} macro to retrieve the build path in a post-build step:
${workspace_loc:/${ProjName}}/${ConfigName}/${BuildArtifactFileName}
Then you can copy target binaries to your common binary folder, or do something other in the build folder of that particular configuration.
If you open up the project's properties, there is a tab C/C++ Build. This has an option for build location, where you can specify the build directory. It seems you could change this for your multiple projects so that they share the same build directory.
Just happened to be working on something that led me down a similar path - so I'll offer it up as an alternate solution/reminder to myself:
In Eclipse (at least in Luna) the generated makefiles are actually rather decent and convenient. I personally like to create several build configurations (Release and Debug variants with 32 and 64 bit architectures), and supplement them with debug and run (F5 and Execute, respectively) configurations.
To continue: I have been toying with packaging on Debian and found - during the act of said toying - that I needed to create and test an install target. Eclipse neither generates for you, nor provides an interface to - a configuration - for customizing or adding an install target; Other than a place where you can specify that another target exists.
So technically Eclipse does provide an interface; kinda. Hence, I stumbled across the makefile.init, makefile.defs, and makefile.targets files.
Process/Workflow:
Create a file makefile.targets in the root directory of your eclipse project; In said file define an install target manually. This - of course - allows you to specify every little detail as you'd like, but with the added benefit of all of the configuration provided by Eclipse already complete and available to you for use with defining the rules for the specified target.
After defining the new target in the makefile.targets file, right click on your project's name or main cpp file in Eclipse's project explorer, and then select Make Targets->Build..., and finally Add to instantiate a pop-up. Alternatively, you could select 'create' in the last step instead of 'build' and it would provide the same pop-up required for the next part. Add the name of your new target and - leaving everything else at their default values - click ok
If you chose to add the new make target by right-clicking in Project Explorer and selecting Make Target->Build..., after adding the new make target you will be brought back to the first pop-up which resulted from selecting Build.... Otherwise, find your way to the Make Targets->Build.. pop-up now. Select the desired target and then click on Build.
Looking through Eclipse's auto-generated makefiles was an excellent way to learn the makefile syntax and overall structure, and get into some advanced usage of includes and conditionals.
Here are some portions of an example makefile, which - at least I hope - will demonstrate manually setting the output directory of a build:
prefix = /usr/local
bindir = $(prefix)/bin
sharedir = $(prefix)/share
mandir = $(sharedir)/man
man1dir = $(mandir)/man1
...
# Typical all target
all: <binaryname>
#Typical clean target
clean:
rm -f <binaryname> <objectname>.o
# Target invokes all, then installs to specified locations
install: all
install <binaryname> $(DESTDIR)$(bindir)
install -m 0644 <objectname>.1 $(DESTDIR)$(man1dir)