[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Preparsed Index Setup Questions
|
Hi Andrew - I left some boogs here:
I'm
still not sure why my indexes aren't fully working. I have two
scenarios:
-----
Scenario 1) The external PDOMs are
read and not re-indexed (correct behaviour), but then all lookups
(F3) fail, looking for includes in the wrong directory. Generating PDOM
as:
-target
c:\Symbian\9.3\S60_3rd_FP2_Beta\epoc32\data\pdom\carbide.sdk.index.pdom -source
c:\Symbian\9.3\S60_3rd_FP2_Beta\epoc32\include\ -id com.example.pdom1
-include
c:\Symbian\9.3\S60_3rd_FP2_Beta\epoc32\include\variant\Symbian_OS_v9.3.hrh
For
example, in this case I get fast index, small PDOM, but F3 takes me to
c:\Symbian\9.3\S60_3rd_FP2_Beta\epoc32\<file.h> instead of
c:\Symbian\9.3\S60_3rd_FP2_Beta\epoc32\include\<file.h>
---------
Scenario 2) The external PDOMs are
found correctly, but during project indexing none of the files are found. PDOM
generated from IDE as (on a virtual/subst drive):
-target p:\epoc32\data\pdom\carbide.sdk.index.pdom
-source P:\epoc32\include\ -id com.example.pdom2 -include
p:\epoc32\include\variant\Symbian_OS.hrh,P:\epoc32\include\gcce\gcce.h
In
this case, the headers that are re-indexed as added with the identical path that
they were added by the external PDOM generator! For example the external PDOM
generator and project generator both say they are adding the same
file.
Indexer: adding
file:/P:/epoc32/include/e32def.h
-------------
In both cases IPDOMDescriptor#getIndexLocationConverter()
turns the path to *\epoc32\include\. So I don't see any problem with the lookup
path I am providing.
Thanks,
Tim
Thanks for the tip Andrew. I'll do some more
experimentation and post patches for the mods I've made for you to look
over.
Tim
hi Tim,
> The project PDOM is the
same size, same headers and added, and about the
> same time to
re-index whether or not the preparsed index is used.
This sounds like a problem with the
IIndexLocationConverter - if the paths
of
includes the indexer requests do not align with those contained in
the
pre-built index, then you get a
situation like a cache miss and the file will
be indexed anyhow. For an external SDK, its likely that you can
use
org.eclipse.cdt.core.index.URIRelativeLocationConverter
initialized with the URI of the logical base of the
index content. For example,
"file:/D:/Symbian/9.5/epoc32/include".
Running some quick benchmarks against HEAD, I see improvements
like
helloworld: 20KiB -> 20KiB, 3s ->
1s
'agenda'
user application: 8MiB -> 940KiB, 12s -> 9s
The time improvement is more modest than I expect
for the second case. The parsing
(not
resolution) phase seems to be taking longer - I'll try to find some time to
see
why.
> 1) Only one preinclude is allowed (-include arg) when generating
a PDOM.
> I have a fix for that if we want to allow > 1 preinclude,
which I don't
> know why we wouldn't.
> 2) Only one source path
is allowed (-source arg). I have a partial fix
> for that, adding
multiple linked directories to be indexed under the
> dummy
project.
The default command-line
(ExternalExportProjectProvider) is very
simple. You
can provide an alternate
implementation with the -pprovider switch, but these
do sound like good enhancements to have - if you're
happy to raise a
bugzilla I'll aim to pick
these up.
> 3) PDOM generation runs
out of memory with too many source files. I can
> log a bug which I
can reproduce, but can't provide sources.
I've not seen this - a bugzilla with details such as number of files,
heap size
etc.. is a good idea.
thanks,
Andrew
**********************************************************************
Symbian
Software Ltd is a company registered in England and Wales with registered
number 4190020 and registered office at 2-6 Boundary Row, Southwark, London,
SE1 8HP, UK. This message is intended only for use by the named addressee
and may contain privileged and/or confidential information. If you are not
the named addressee you should not disseminate, copy or take any action in
reliance on it. If you have received this message in error please notify
postmaster@xxxxxxxxxxx and delete the message and any attachments
accompanying it immediately. Neither Symbian nor any of its Affiliates
accepts liability for any corruption, interception, amendment, tampering or
viruses occurring to this message in transit or for any message sent by its
employees which is not in compliance with Symbian corporate policy.
**********************************************************************