IProjectFileManager::import and parse

[Matt Rogers]

On Jun 21, 2007, at 6:13 PM, Andras Mantia wrote:

> Hi,
>
>  I'd like some extra information about the above methods as the docs,
> well, they are not very detailed. ;)
>
> As I understand import shouldn't do anything else but return the
> toplevel project item, usually the toplevel folder of the project.

Before it returns the toplevel project item, the toplevel directory  
should be parsed just like other directories would be. Ideally, it  
should also do some neato detection thing to make sure that the  
various things required by the buildsystem are there before starting  
that parsing. For example, in the CMake manager, we check to make  
sure that there is a toplevel CMakeLists.txt

> As *I* understood, parse would then parse the *whole* project and  
> return
> a list with the folders belonging to the project, and *only* folders
> (probably not the files, as they are anyway children of folder items).
>
> Well, the main problem is that the shell has a different idea of parse
> than I do, as it works like this:
> - call parse, get a list of directories
> - call parse for each of the directories from the above list
> - repeat this until no directories are found
>
> So this is a recursive call.
>

Actually, it's not truly recursive. See below.

> The documentation for parse is: "This method initialize the model  
> item."
>
> So the questions:
>
> 1) Why shouldn't parse be the recursive method instead of the
> ImportProjectJob::start() ? The problem with the recursiveness in the
> upper level is that sometimes a project file can contain just some  
> urls
> to the files belonging to the project (somewhat similar to KDevelop's
> custom project). In such a case it is really hard to provide first the
> top-level directories, then the ones one level below (separately for
> each top-level directory), and so on. This would require multiple
> parsing of the project file. For such cases its much simple to parse
> the project file once and create *every* Project*Item there.
>

The additional calling of parse for additional folder items is  
handled by the ImportProjectJob. It's done this way to avoid the  
recursion problem. parse() only needs to return a list of project  
folder items. the folders represented by those items can be random  
and spread throughout the filesystem.

Could you please define "project file" more clearly. When you say  
"project file", I think of the .kdev4 project files. I don't know  
what you mean by project file. Knowing this will allow me to better  
answer your question, since I don't think I've really answered it.


> 2) Is there a real need to "parse" for anything else than the top  
> level
> item? Of course now it is, due to the code in ImportProjectJob::start,
> but I don't see any other need for it. The project file manager plugin
> should read only once the project file: when the project is loaded. If
> there is a need for a list of files/folders under one folder, this  
> list
> should (and can) be obtained from the Project*Item tree structure.
>
> 3) Why is there the "import" and "parse" separation, if parse could  
> also
> create the top level item as well?
>
> Of course 1-2-3 depend on each other. ;)
>
> Andras

Since 2 and 3 depend on 1, I can't answer those until you answer my  
question about what you mean by "project file".
--
Matt