On 2011-02-08, at 9:45, Vlad Dumitrescu <[email protected]> wrote:
>
>
> On Tue, Feb 8, 2011 at 14:05, Alain O'Dea <[email protected]> wrote:
> On 2011-02-08, at 7:30, Vlad Dumitrescu <[email protected]> wrote:
>
>> On Tue, Feb 8, 2011 at 11:47, Jakob Cederlund <[email protected]> wrote:
>> 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.
>>
>> ErlProjectInfo contains more information than the layout: the used runtime,
>> referenced projects and libraries, compilator settings, etc.
>>
>> ErlProjectLayout describes the layout of this project.
>> References to external projects/libraries can also use ErlProjectLayout.
>>
>> The model should have API to change the layout: for example to recognize the
>> 'test' directories as containing source code that should be compiled. But
>> this API should not be used to traverse the directories and search for erl
>> files -- the model will provide an API for that instead.
>>
>> regards,
>> Vlad
>
> Just to throw a wrench in the works: Zotonic uses several wildcard source
> paths. See
> http://code.google.com/p/zotonic/source/browse/Emakefile?r=release-0.6.x for
> more detail.
>
> It seems sensible to me to use Emakefile as the storage format for source
> paths and compiler settings. The more Eclipse-specific the settings, the
> higher the friction in getting people using it.
>
> You're welcome! :-)
>
> I was thinking about an expanded .app file instead, because there is
> information from there that is useful, too.
>
> regards,
> Vlad
An expanded .app would be a lovely solution :)
More config files and build files and Erlang will start to be more like Java
(read: less fun and productive). I'm all for expanding the .app file. It
would be the logical point from which to import projects as well :)
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/erlide-devel