# 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
