RE: [cdt-dev] PathEntryUtil should honor cygwin absolute paths

["Sennikovsky, Mikhail" <mikhail.sennikovsky@xxxxxxxxx>]

I guess the logic of path conversion should reside in the Build System, but not in the Path Entry mechanism, since it’s the build system who knows what tool-chain is being used and how the tool-chain treats path information. The Path Entry in its turn should work with OS paths as it does now.

So I propose making the enhancement in the Build System if necessary to properly convert the include path information when calculating path entries.

 

Mikhail

 

---

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Ploett, Norbert
Sent: Tuesday, September 05, 2006 12:18 PM
To: CDT General developers list.
Subject: [cdt-dev] PathEntryUtil should honor cygwin absolute paths

 

Hi folks,

 

here is something I encountered:

 

defined a new project type for managed make. The toolchain is win32 / cygwin. The compiler gets a few additional include paths which are absolute cygwin style paths, like so: "/aud/aud_dev/windows_tools/i586-aud-linux/includeAuD" I like to do this because the additional #includes will be installed in location which is constant only relative to the cygwin root.

 

When I create a new project with these settings I get a warning in the problems window:

 

Invalid project path: Include path not found (\aud\aud_dev\windows_tools\i586-aud-inux\includeAuD).  

Looking into the code for a little, here is where I see the problem:

 

class PathEntryUtil:

 private static boolean isValidExternalPath(IPath path) {
  if (path != null) {
   File file = path.toFile();
   if (file != null) {
    return file.exists();
   }
  }
  return false;
 }

The path is simply fed into a Java File and, no wonder, this fails for my configuration. Before trying this there should be a test whether the tool which has this path is a cygwin tool, and if this is so, then the path must be translated first.

 

There was some discussion about how to find this out already and I see two  approaches:

 

a) Pragmatic: If the first attempt fails, test whether eclipse is running on Windows, if that is so then try to convert the path a la cygwin and retry.

b) Clean: Find out from the toolchain settings whether this tool needs a path conversion and if so then do the conversion before testing the existence of the include path.

 

Any suggestions on this? Especially I would like to know whether the information is already present somewhere in the MBS settings or available via the scanner discovery framework resp. a place where it would just be a minor extension to get the information.

 

 

Thanks for opinions

 

 

Norbert