Do we need both ErlProjectInfo and ErlProjectLayout? In any case, I propose
that they are internal to the core plugin, and that all external exposure of
the project is made through IErlProject.
/Jakob
2011/2/8 Vlad Dumitrescu <vladd...@gmail.com>
> # Step 1: project structure
>
> By project structure (or layout) I mean the places where files are located
> in a project. I suggest to use the code_path as the base for defining the
> project structure, extended so that it can refer to source code too, not
> only beam code (suggested name to avoid confusion: source_path). A similar
> approach is used by the Java tools.
>
> Unfortunately, we must support project structures that don't follow the OTP
> standard and that aren't even self-consistent... So we need a flexible way
> to describe those.
>
> * A project's source_path is a list of source_path locations.
> * A basic source_path location points to a list of 'source' directories, a
> list of 'include' directories and an 'ebin' directory (and also 'doc' and
> 'priv' directories), so it's basically the structure of an OTP application,
> slightly extended. If 'ebin' is not specified, the project uses a default
> shared value. (See ErlProjectLayout class)
> * "External references" point to libraries, other projects or other
> applications, outside of the current project. They are described similarly,
> but of course used differently (code is not compiled, for one thing).
>
> We need an API to retrieve these for each different use - for example "get
> source directories to compile" only return internal source_paths, "get
> source directories for navigation" will return even external references. For
> the first steps we can have these different uses hardcoded.
>
> ErlProjectInfo, ErlProjectLayout and related classes implement some of
> this. There is also an app_meta.erl file that supports persistence of
> project information in a format similar to OTP .app (I have described it in
> a message to erlang-questions, but there was no reaction, so I don't know if
> it means it's simply stupid or if it's of no interest outside erlide)
>
> regards,
> Vlad
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Erlide-devel mailing list
> Erlide-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/erlide-devel
>
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Erlide-devel mailing list
Erlide-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/erlide-devel
