Bug 280440 - Include paths with unset environment variables look strange in C/C++ Projects tab
Summary: Include paths with unset environment variables look strange in C/C++ Projects...
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-core (show other bugs)
Version: 6.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 275779
  Show dependency tree
 
Reported: 2009-06-16 08:06 EDT by Jens Seidel CLA
Modified: 2020-09-04 15:17 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Seidel CLA 2009-06-16 08:06:43 EDT
Build ID: 3.5 I20090605-1444

Steps To Reproduce:
Compare also with #101643.

The project properties of my project look strange. Under "C/C++ General" -> "Paths and Symbols" I see as "Includes" -> "Include directories":

${CDTUSERDEFINEDINCLUDEPATH1} [exp]
debug/${CDTUSERDEFINEDINCLUDEPATH2}
debug/${CDTUSERDEFINEDINCLUDEPATH3}

First of all I don't know what "[exp]" stand for. But I wonder about the "debug/" prefix for variables 2 and 3. The .cproject files starts with:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?fileVersion 4.0.0?>

<cproject>
<storageModule moduleId="org.eclipse.cdt.core.settings">
<cconfiguration id="org.eclipse.linuxtools.cdt.autotools.configuration.build.1941485492">
<storageModule buildSystemId="org.eclipse.cdt.managedbuilder.core.configurationDataProvider" id="org.eclipse.linuxtools.cdt.autotools.configuration.build.1941485492" moduleId="org.eclipse.cdt.core.settings" name="release">
<externalSettings>
<externalSetting languages="org.eclipse.linuxtools.cdt.autotools.gnu.toolchain.tool.configure.957821449.languagedata">
<entry flags="VALUE_WORKSPACE_PATH" kind="includePath" name="/myProject/src"/>
<entry flags="" kind="includePath" name="${CDTUSERDEFINEDINCLUDEPATH1}"/>
<entry flags="" kind="includePath" name="${CDTUSERDEFINEDINCLUDEPATH2}"/>
<entry flags="" kind="includePath" name="${CDTUSERDEFINEDINCLUDEPATH3}"/>

Previously I think the file contained entries
"${CDTUSERDEFINEDINCLUDEPATH1}"
"../${CDTUSERDEFINEDINCLUDEPATH2}"
"../${CDTUSERDEFINEDINCLUDEPATH3}"
since this inconsistency looked strange I just removed "../" as I know it works for variable 1.

The only difference between all three variables is that I only use the first and the other two are unset and exist for later extensions only.

Shouldn't all three variables handled equally?

More information:
Comment 1 Andrew Gvozdev CLA 2009-06-16 09:37:33 EDT
Thanks for the report. I agree it is confusing and should be corrected to saner behavior.

I do not take that as an excuse but if you look under the hood - it tries to figure out if it is absolute or relative path. PATH2 evaluates to relative so it treats it as relative to the project root. The tool settings (-I) which are persisted in .cproject are relative to build directory which is "Debug/" for managed project. That's where it comes from. I think you are better off where you are now (having "${CDTUSERDEFINEDINCLUDEPATH2}" in .cproject) and just ignoring "Debug"  as an oddity.