[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:
 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=219673 - can't add multiple includes to generate external PDOM
 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=219674 - no support for multiple source paths for external PDOM generation
 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=219678 - out of memory errors
 
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
 
 
 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
Sent: Wednesday, February 20, 2008 9:31 AM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Preparsed Index Setup Questions

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


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
Sent: Wednesday, February 20, 2008 7:21 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Preparsed Index Setup Questions


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.
**********************************************************************