Hi Richard,
This seems to be a bug in
the backward compatibility mechanism that translates the path entries settings
to the CProjectDescription settings.
Please raise a bug
regarding this.
BTW it is strongly
encouraged to use the ICProjectDescription API for manipulating with
includes/symbols/libs settings for the new-style projects since this new API
allows specifying settings on a build configuration basis as well as allows per-language
settings.
Once you are using the old
IPathEntry API for modifying includes/symbols/libs for the new projects you do
not have a control over multiple configurations settings as well as you are forcing
all languages to have the same includes/symbols settings.
Regards,
Mikhail
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard Miskin
Sent: Friday, May 18, 2007 5:05 PM
To: CDT
General developers list.
Subject: [cdt-dev] Possible
problem with setRawPathEntries in CDT 4.0 M7
Hi,
I think I’ve found a problem with
setRawPathEntries but I’m not sure so I thought I’d mention it here
before raising a bug.
The following code demonstrates the problem I’m
having
ICProject cProject = CoreModel.getDefault().create(proj);
IPathEntry[] oldEntries;
try {
oldEntries = cProject.getRawPathEntries();
System.out.println("Before: " + oldEntries.length);
IPathEntry[] newEntries = new IPathEntry[oldEntries.length +
1];
System.arraycopy( oldEntries, 0,
newEntries, 0, oldEntries.length);
newEntries[oldEntries.length] =
CoreModel.newIncludeEntry(Path.EMPTY,
Path.EMPTY,
new Path("C:\\"),
false);
CoreModel.setRawPathEntries(cProject,
newEntries, new NullProgressMonitor());
IPathEntry[] a = cProject.getRawPathEntries();
System.out.println("After: " + a.length);
} catch (CModelException e) {
e.printStackTrace();
}
With CDT 3.1.2 this code will add C:\ as an include
path and size of cProject.getRawPathEntries is one larger after the set than it
was before as you might expect. With CDT 4.0 C:\ doesn’t get added as an
include path and cProject.getRawPathEntries is 2 bigger with a MinGW C project
and 10 bigger with a MinGW C++ project.
Looking at the Project Explorer shows the includes
being changed from
C:/MinGW/Include
C:/MinGW/Include/lib/gcc-lib/mingw32/3.2.3/include
/MinGW/Include/
/MinGW/Include/lib/gcc-lib/mingw32/3.2.3/include
to:
ProjectName/MinGW/Include/
ProjectName/MinGW/Include/lib/gcc-lib/mingw32/3.2.3/include
C:/MinGW/Include
C:/MinGW/Include/lib/gcc-lib/mingw32/3.2.3/include
/MinGW/Include/
/MinGW/Include/lib/gcc-lib/mingw32/3.2.3/include
The same problem occurs on Linux.
Am I doing something wrong in my code that just
happens to work with CDT 3.1.2 or is this a bug in CDT 4.0?
Cheers,
Richard
The information transmitted is intended only
for the person or entity to which it is addressed and may contain confidential
and/or privileged material. If you are not the addressee, any disclosure,
reproduction, copying, distribution, or other dissemination or use of this
communication is strictly prohibited. If you have received this transmission in
error please notify the sender immediately and then delete this email.
Any representations or commitments expressed
in this email are subject to contract.
This message has been scanned for viruses and
dangerous content. However, it is essential that the recipient also checks this
message using commercially available mail scanning and anti-virus software. IPL
Information Processing Limited accepts no liability for any loss or damage
resulting from any virus or other dangerous content in this message.
IPL Information Processing Limited is
registered in England and Wales under company registration number 1418818.
Registration took place at Cardiff on 10 May 1979. IPL Information Processing
Limited's registered office and normal place of business is Eveleigh House,
Grove Street, Bath, BA1 5LR, United Kingdom. IPL is also registered for Value
Added Tax (VAT) under registration number GB 601 2931 83.