Use eclipse build variables to create project include directories, in C++ - c++

I have a C++ project in Eclipse which the base part of all include directories is different depending on a chosen platform. For example, including include/cTable directory:
/a/b/c/platform1/include/cTable/
/a/b/c/platform2/include/cTable/
/a/b/c/platform3/include/cTable/
So, what i want to do is to create next build variables (window->preferences->C++->build->build variables):
PLATFORMNAME_PLAT1 = "platform1"
PLATFORMNAME_PLAT2 = "platform2"
PLATFORMNAME_PLAT3 = "platform3"
PLATFORM_SELECTED = ${PLATFORMNAME_PLAT1}
INCLUDE_DIR = "/a/b/c/${PLATFORM_SELECTED}/include/"
Then, using the project properties, C++ general->paths and symbols->includes, add include directories that way:
${INCLUDE_DIR}/cTable
${INCLUDE_DIR}/cRow
${INCLUDE_DIR}/cComponentBase
${INCLUDE_DIR}/cTimers
That way, when changing the platform, i only have to edit the PLATFORM_SELECTED build variable, setting it to the PLATFORMNAME i want, even without remembering the platform directory name.
The problem is that the INCLUDE_DIR variable is not expanded and i have lot of errors like "invalid project path: include path not found (/a/b/c/include/cTable)". I think that the problem is the type of the build variables. INCLUDE_DIR has Path type, but i've tested using both path and string types for the other without any success. I would like to ask if someone can point me to a good approach for the creation of these build variables.
I dont use eclipse for compiling, but just for code editing, so what i want is to use the code completion and syntax highlighting.

Related

How to define custom build variables in Xcode

In Xcode 10, I'm creating a C++ project that uses the HEADER_SEARCH_PATH to define a list of header include paths. One of the paths contains an environment variable, e.g. ${CUSTOM_INCLUDE_ROOT}/boost_1_xx_0/include, where ${CUSTOM_INCLCUDE_ROOT} is supposedly an environment variable to be set on each dev's local environment to give a root include path - the reason is that this root dir is of user's own choice, so different users can decide on different root dir.
However, in Xcode 10 build settings, it doesn't seem that Xcode is automatically expanding ${CUSTOM_INCLUDE_ROOT} - causing the expanded header to look like: /boost_1_xx_0/include, and of course that causes compiler errors for #include <boost/something.hpp>
So, the question is: how does Xcode build settings reference environment variables, or is this possible at all?
Or a related question would be: if referencing environment variables in build settings is not possible, is it possible to define new custom variable such as ${CUSTOM_INCLUDE_ROOT} to be /home/username/globalInclude inside xcode?

Eclipse C++: fatal error: cheddar.h: no such file or directory

[RHEL v7.3, Eclipse Photon, C/C++ Project with Eclipse-generated Makefile]
Attempting to include a custom library named cheddar.h results in
Fatal Error: cheddar.h: no such file or directory
Research 1 and 2 suggests manually adding the include path by first alt-clicking the project in Project Explorer, and then manually adding the path :
Properties -> C/C++ General -> Paths and Symbols : Includes : Languages, GNU C++
No luck.
It works if I do things the old-fashioned way, and add the path to the makefile with a -I option, like so
-I/home/kmiklas/lib/
..but I feel like I'm working-around the issue, and I want this set up properly; the way it should be set up.
How do I correctly specify a custom include path in Eclipse? Tyvm :^)
What is wrong with CMake/Makefile?
I don’t know, but this just sounds like an XY problem. But what’s even more confusing is how you’re so reluctant to use a solution that you’ve already got (as in it’s bugging me).
Anyway
What may aid you in this is to ditch eclipse’s settings and just use the compiler’s. Eclipse uses (GCC/G++ (probably)). What you can do is set some environment variables DUN DUN DUHH!
These environment variables are aptly named: C_INCLUDE_PATH and CPLUS_INCLUDE_PATH. If, however, you want the same for both (you want to use it for both languages) you can just set CPATH.
You’re probably thinking: what else can I do with this marvel... and for that I direct you to the official GCC website.

How to add an include directory based on environment variable in RHIDE without expansion?

The REDHAWK IDE insists on expanding environment variables when creating the Makefile.am.ide file. For example, assume that $SRC_ROOT is /srcpath and I add an include path in the Path and Symbols window of the C/C++ section of my project as below:
${env_var:SRC_ROOT}/include
the generated Makefile.am.ide file contains:
rehawk_INCLUDES_auto = -I/srcpath/include
when what I really want is:
rehawk_INCLUDES_auto = -I$(SRC_ROOT)/include
This is important because this file is used by other team members that have different values for $SRC_ROOT. Currently we have to put the include path in Makefile.am, but then the IDE doesn't see the header files in the directory and sees errors for the code referred to in the missing headers.
Is there anyway to get RHIDE, to not expand the environment variables when it generates Makefile.am.ide?
Not exactly what you are looking for but you can always disable the auto-updates of the Makefile.am.ide by disabling the REDHAWK C++ auto-inclusion builder. This is in the projects properties in the Builders section.
This will allow you to add to Eclipse's Paths and Symbols section without the auto-inclusion builder picking it up and adding it to your Makefile.am.ide.
If you do choose to disable this builder you will then need to manage the addition of new source files on your own.
Youssef's answer is not a bad one, but I've come up with a different way to work around the problem. In Makefile.am, override the redhawk_INCLUDES_auto value to be what I what it to be:
include $(srcdir)/Makefile.am.ide
#Override the value from Makefile.am.ide that may be wrong!
override redhawk_INCLUDES_auto = -I$(SRC_ROOT)/include
This requires one to update any custom include directories in both the IDE and the Makefile.am file, but managing the source files is still automatic.
It still has the issue that the Makefile.am.ide file's contents will be different for other developers which complicates version control. So I don't consider this be a complete answer to the problem.

Eclipse can't find header filers even though include paths have been set

When creating a new C project in a particular Eclipse environment which uses GCC, I run into a peculiar linker problem:
Fatal error: my_header.h: No such file or directory.
I get this problem since "my_header.h" resides in a sub folder. After investigation, I found out that you need to include sub folders in the GCC include path (option -I). How this is done seems to vary between different Eclipse implementations, but it should be something like
Project -> Properties -> C/C++ Build -> Settings -> Compiler -> Includes
Where "compiler" may have a different name in different implementations, and "includes" may be called "input" or similar.
There should be an option to add the include path (option -I) where you can set the path relative to the specific project, by clicking an "Add" icon followed by Workspace button, then select the directory. Eclipse then generates a path, which should look something like
"${workspace_loc:/${ProjName}/app}"
Do this for all sub folders in the project (and their sub folders).
But despite doing the above for the relevant folder, I still get the "no such file or directory" error. What could be the problem?
(I'm posting this Q&A style since I want to share the solution of this problem with others)
The reason for this error is that there is no sanity check for the gcc include path. Despite giving a relative path to Eclipse as described, Eclipse will still pass an absolute path to gcc -I.
Suppose you have your project located at a path like:
C:\åäö\workspace\project
and the sub folder located at
C:\åäö\workspace\project\std
where "åäö" is any string containing any non-standard ASCII letters. In this example I used Swedish, but you'll encounter such non-standard letters in most languages (French, German, Spanish etc).
The problem is that Eclipse passes the full path, rather than the relative one to GCC, and then there is some sort of symbol table mishap. So rather than getting the expected
-I"C:\åäö\workspace\project\std"
you might get random garbage letters such as:
-I"C:\#!#\workspace\project\std"
The path doesn't make sense and the include path is not sanity checked, so you get no diagnostic telling you about this, unless you read the console output in detail. Instead, Eclipse silently pretends that it has added your include path to the list of paths it should check, even though it has not.
The only solution seems to be avoiding placing your projects below paths that contain non-ASCII letters. It would seem that this is a bug in several implementations of Eclipse that use GCC.

How can I put $(SRCROOT) into a string?

Or is there any other way of getting the project's directory into a string? I have tried this
const char* filepath = std::getenv("SRCROOT");
But filepath shows up as null, it works on other environment variables though. Does SRCROOT have some kind of in-code alias? I can't just use "../", I need the full path in a string.
The best option I've found is to define the macro under Other C Flags on your project properties according to ${SRCROOT} env variable. Here's how :
Than you can use the SRCROOT on your C/C++ code as constant string.
As for the project's directory, check your IDE documentation for environment variables. It may have a translation that will create a macro with the project's directory.
The executable's directory can usually be obtained from the first parameter passed to the main function.
Otherwise project directories, especially directory structures, are platform dependent. Some platforms, such as embedded systems, don't have directories, only memory. Consult your operating system for more information.
As an alternative, you may be able to have your build system pass the project name as a define on the command line. Other ideas are to create environment variables or configuration files; all should be done by the build system.