RE: [cdt-dev] Creating a ScannerConfigurationDiscoveryProfile for gcctyp

["dmsubs" <dmsubs@xxxxxxxxxxxxx>]

Norbert,

I came across this problem, and it was answered by Jeremiah Lott on this
list in February. There is actually a special class for Cygwin.

Try replacing

class='org.eclipse.cdt.managedbuilder.internal.scannerconfig.DefaultGCCS
cannerInfoCollector'

with:

class='org.eclipse.cdt.managedbuilder.internal.scannerconfig.DefaultGnuW
inScannerInfoCollector'

HTH
---
Derek  

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Ploett, Norbert
> Sent: 03 April 2006 13:55
> To: CDT General developers list.
> Subject: [cdt-dev] Creating a 
> ScannerConfigurationDiscoveryProfile for gcctype cross 
> compiler based on Cygwin
> 
> Hi folks,
> 
> it all started with me creating a new project type for a gcc 
> type cross compiler on Cygwin. The compiler has the path 
> /aud/aud_dev/windows_tools/bin/i586-aud-gcc (i.e. a Cygwin-absolute
> path)
> 
> First thing I observed that the includes path entry container 
> still lists the built-in paths of the default gcc. After a 
> while I figured out that I must define my own 
> ScannerConfigurationDiscoveryProfile for my toolchain.
> 
> Copied the GCCWinManagedMakePerProjectProfile to my plug-in 
> with all the elements below and just changed the name and the 
> compiler command in the run element.
> 
> Now the GCCSpecsRunSIProvider gets called alright with 
> /aud/aud_dev/windows_tools/bin/i586-aud-gcc as the compile 
> command, but this does not work it invokes the 
> CommandLauncher's execute() method.
> The compile command's path is there changed into an OS string 
> without taking into account that the absolut-looking 
> /aud/aud_dev/windows_tools/bin/i586-aud-gcc is actually 
> relative to Cygwin's root directory. Which could vary from 
> one machine to another.
> Consequently the compiler is not found and the discovery fails.
> 
> What do I do now? I think that the GCCWinManagedMakePerProjectProfile
> (and clones like mine) is made for the Cygwin environment and 
> should therefore be able to handle Cygwin paths. So I think 
> this is probably a bug.
> 
> How do we fix this? Is there already a place somewhere in the 
> CDT from which the Cygwin root could be queried? Any other 
> ideas from anybody on getting a fix on this?
> 
> Thanks a lot
> 
> 
> Norbert Ploett
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev