Once I have set the include directories and linking directories for an Eclipse project in debug configuration, is there an easy way to copy them over to the release configuration without entering them in again manually (or vice versa)?
In the project properties, in the field Configuration, you should choose between Debug, Release and All Configuration. If you select "All configurations", everything you set will be applied to Debug and Release.
The issue is that, sometimes, include and linking directories depends on the configuration. For instance : ".../Include/Debug" or ".../Include/Release". In this case, you can still use "All Configurations" and write ".../Include/${ConfigName}"
ConfigName is an Eclipse variable that is automatically preset to Debug or Release according to the configuration.
${Var} means that you want to include the value of Var. In the example above, the string will be understand by Eclipse as ".../Include/Debug" or ".../Include/Release" according to the configuration.
You can add your own variable in Properties / C/C++ Build / Build Variables, in order to do more powerful things.
Related
This question provides good answers to the question of excluding files from indexing that are also excluded from a build. An open question remains: how does one prevent files that are part of the build from populating the code-completion or code-insight functions?
My use-case is a TrueSTUDIO (was System Workbench, was bare Eclipse) project which includes some modules from another project. They are wrapped in safe-to-use stubs and wrappers and should never be called directly. The external modules cannot be edited because they must stay in sync with the other project, so their filenames and other symbols clash confusingly with the current project's. When using code completion to include a header or complete a function name, the filenames and function names of the modules that are not to be used directly appear in the completion lists.
I wish to continue to include the modules in my builds, but not have any of their contents appear in the code-complete/insight features.
I see in Project Properties -> C/C++ General -> Indexer there are options to configure the indexer to use a different build configuration. This is promising, but will probably quickly lead to a indexer that is sorely out of sync with the primary build configuration.
Any advice on a practical method?
The only way I found to exclude files from Eclipse indexing is using the abovementioned Indexer-specific build configuration. In my case, it helped with the annoying problem of indexer freezing on .cu (NVidia CUDA) files.
This is how it works:
Prepare a new (Indexer-specific) build configuration.
Exclude unwanted source files from this configuration using the
Source Location exclude filter.
Let Indexer use this particular build configuration.
Eclipse configuration is a bit tricky with Indexer, so this is a step-by-step guide (as for Eclipse 2021-09):
Preparing a new build configuration:
Project->Build Configurations->Manage->New:
Give it a name, e.g., "4indexer".
Select "Copy settings from" with your preferred configuration. In my case, "Debug" worked just fine.
Excluding unwanted source files:
Project->Properties->Paths and Symbols->Source Location:
Select "4indexer" as the configuration to be managed on the top of the properties window.
Apply an exclusion pattern of your choice. In my case, I added "*.cu" at the end of the "Source Folder Exclusion Patterns" list by clicking Add... button and typing *.cu in the "Add Exclusion Pattern" text field.
Reconfiguring Indexer:
Window->Preferences->C/C++->Indexer:
Allow any Indexer to work with a project-specific build configuration (it was tricky to figure it out): check the "Use the build configuration specified in the project's indexer settings" radio button.
Project->Properties->C/C++ General->Indexer:
Check the "Enable project specific settings".
Select the new build configuration for your project Indexer: check the "Use a fixed build configuration" and select "4indexer" from the drop-down list below.
I also unchecked the "Index source files not included in the build", but I'm not sure if it is necessary.
Sometimes Indexer is trying to reindex a project as you try to reconfigure it, freezing Eclipse. So, I turned it on and off and restarted Eclipse a few times.
I have project with qt-gui and command line only version.
I have release and debug configuration for both gui and non gui version. I want to have different names for debug configuration in gui and non gui version. But when configuration has different name than Debug, debugging does not work and it behaves like release build.
Is there any possibility to have multiple debug configurations, each with different name?
Note, if you click on "Debug" configuration, the following hint is shown up underneath the "CMake options":
-DCMAKE_BUILD_TYPE=Debug will be passed automatically
So, you shouldn try to add -DCMAKE_BUILD_TYPE=Debug into "CMake options" expliticly when you create your own configuration with a different name, which is inherently a Debug configuration
I have two projects in my solution. I am currently using the default configuration mode which is 'Debug'. When I want to do a 'Release' build, I switch to Release-mode and then I see all my previous projects properties are set to default, meaning I have to add all properties again manually to this mode.
Is there a convenient way to solve this in VS2010, for example to copy all properties like include paths, preprocessor macros, build macros, etc from 'Debug' to 'Release' mode?
Configuration settings are stored in .vcproj / .vcxproj file. You could open it in some text editor and copy some settings manually, but it wouldn't be convenient. For now you could just open projects properties and copy these settings while switching Debug / Release configuration in the upper left corner of that window.
Next time when you are setting properties that are intended to be the same for all configurations, choose Configuration: All Configurations to avoid troubles.
Property sheets can solve this and a few other property-related issues with ease.
In short, all the properties in a project are just nodes in an XML document, and the property group nodes can have a condition attribute. They're easy to change in any text editor, but a lesser-known feature is the ability to import other XML documents, which can provide settings (for all but a few project-specific ones).
This blog post has a good tutorial on using project sheets, and some more info in this question. You can create them in Visual Studio, edit them (including copying your existing project settings over), then attach them to your project with the property manager (not the property window).
The groups in your property sheet use the same syntax as regular settings, and can be set for all configurations or filtered to only apply on some. They can also be filtered by project name and a few other things, using VS' variable and condition system. For example, I use:
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<ClCompile>
<WarningLevel>Level4</WarningLevel>
<TreatWarningAsError>true</TreatWarningAsError>
<Optimization>Disabled</Optimization>
<EnablePREfast>true</EnablePREfast>
<RuntimeLibrary>MultiThreadedDebugDLL</RuntimeLibrary>
</ClCompile>
</ItemDefinitionGroup>
for some of my builds, to apply the same settings to all project (full file here).
One of the most convenient uses is giving the build directory in the file, so all your projects build uniformly into the same directory (make sure to use the project name for the output).
Managing almost all the properties across multiple different builds (debug, release, win32, x64 etc.) can be accomplished with a single collection of settings by using Macros.
Thus, before editing a project settings, make sure you've set Configurations to All Configurations and, Platform: to All Platforms. Now almost all settings can be done in this way, across all the different configurations. Say, you want different configurations and platforms to use different versions of various libraries. Assuming you are using a naming convention that's consistent across all projects, you can then use:
Additional Library Directories: ..\..\foo\bar\lib\$(Platform)_$(Configuration)
You can see what macros will expand to, by hitting the edit button, and then clicking on the Macros>> button.
You could also recreate the new mode you want using the configuration manager and then you can choose from which configuration you want to copy all the settings.
I have a Makefile that based on given target (all/debug) generates executable in release/debug directories on the project folder.
I have setup the Eclipse-CDT C/C++ build behavior mechanism to generate the right output depending on the active build configuration.
For example the "release" build configuration will call "make" with "all" as the behavior, that makes release/output file, "debug" configuration makes a debug version at debug/output
So far so good, but when I need to setup the "run configurations" I should enter the path for the binary (search project just does not show anything), Variable ${ConfigName} also does not expand there so I cannot use something like ${ConfigName}/output as binary to run/debug.
I also tried adding release and debug to the "Paths and symbols"/"Output location" and that not help either.
I can enter the relative/absolute path (for examle ./release/output) there and if I hit run, it runs the binary or if I hit debug it debugs it. However, because of the reliance on the path I have to have two launch configurations one for debug and one for release.
The problem is that run and debug configurations are basically the same only one has the option to customize gdb, which makes it very confusing. Regardless of whether it is debug or release active, one can run/debug any of the four combinations!
Is there anyway I can run/debug what actually is built? so if the debug build is active one can run/debug the debug build? I am not even constraining the debug build to be non-runnable or the release build to be non-debuggable, I guess that is asking too much. The problem is because of the two launch configurations, and I cannot find anyway to make it just one that depends on the build configuration.
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)