Re: Unified project interface

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> On 07/28/2015 04:21 AM, Stephen Leake wrote:
>
>>> Could you give an example?
>>
>> Ada, gradle.

> I meant an example (or several) of those declarations from an actual
> project file.

>From an Ada project file:

aggregate project Books_Agg is
   for Project_Path use
     ("../../../org.stephe_leake.sal/build/release",
      "../../../org.stephe_leake.gtk/build/release",
      "../../../org.stephe_leake.makerules");

   for Project_Files use ("books.gpr");

end Books_Agg;

with "gtkada";
with "gnatcoll_sqlite";
with "sal";
with "sal_gtk";
with "standard_common";
project Books is
   for Source_Dirs use ("../../source", "../../test");

...

end Books;


Project_Path says where to find projects (there is also an implicit
system location); 'with "...";' says what projects to include. In this
case, "gtkada" and "gnatcoll_sqlite" are in the system location, and are
read only; sal, sal_gtk and standard_common read/write. But the Ada
project tool (as provided by the compiler vendor) makes no distinction
between "system" and "user" libraries; more precisely, it relies on the
file system read/write permissions to do that.


>From an Android gradle file:

dependencies {

    compile project(':licensesdialoglibrary')
    compile project(':quickScroll')
    compile project(':velocityviewpagerlibrary')
    compile project(':dragsortlistviewlibrary')
    compile project(':viewpagerindicatorlibrary')
    compile project(':circularImageView')
    compile project(':picasso')
    compile files('libs/android-async-http-1.4.2-66-g4b6eb97.jar')
    compile files('libs/commons-io-2.4.jar')
    compile files('libs/commons-lang3-3.1.jar')
    compile files('libs/commons-logging.jar')
    compile files('libs/dashclock-api-r2.0.jar')
    compile files('libs/google-http-client-1.16.0-rc.jar')
    compile files('libs/google-http-client-android-1.16.0-rc.jar')
    compile files('libs/jaudiotagger-2.0.4-20111207.115108-15.jar')
    compile files('libs/libGoogleAnalyticsServices.jar')
    compile files('libs/universal-image-loader-1.9.3-with-sources.jar')
    compile files('libs/com.haarman.listviewanimations-2.6.0.jar')
    compile files('libs/nineoldandroids-2.4.0.jar')
    compile files('libs/renderscript-v8.jar')
    compile 'com.android.support:support-v4:+'
    compile 'com.google.android.gms:play-services:+'
}

Some of these are read/write, some are read-only; gradle does not have a
mechanism to indicate that.


> Here an excerpt from an imaginary Gemfile:
>
> gem 'foo', '~> 1.2.3'
> gem 'bar', path: '../bar'
>
> Having the latter kind of declaration might not be considered the best
> idea, but it's often nice to be able to do that. Anyway, I'm sure
> there are corresponding configurations in other ecosystems that are
> more idiomatic.

The point is that the abstract project API must handle all of these. In
the case of Ada, there is a command-line tool that parses the project
file and provides the info that Emacs needs.

>> I don't know who this "we" is, but I usually structure a large project
>> as a main with several lower level libraries, all of which I maintain,
>> and I edit them all together to implement new functionality in main. So
>> that has to be a choice.
>
> IME, aside from a few libraries one (person/team/company) maintains
> themselves, there's also a long list of external dependencies.

Yes, we are agreeing; some dependencies are read/write, some are read-only.

How many of each, and whether they are "system" or not, are minor
issues.

> In the example above, 'bar' will be one of project-directory-roots,
> and 'foo' will only be in project-search-path.

Why? What effect does that have on what you can do with 'foo' vs 'bar'?

How can you tell that just from the gem file?

I'm guessing you are saying "foo is maintained by the same team as the
main project (ie read/write), bar is maintained elsewhere (ie
read-only)".

So then files in project-directories are read-only, files in
project-search-path are read/write.

But the current default implementation of project-search-path _inludes_
project-directories, so this is inconsistent.

And we've said that project-directories includes the main project root,
so that's also inconsistent.

So I don't understand what you are doing here.

>> Actually, 'xref-find-regexp' should be named 'project-find-regexp' (or
>> prj-find-regexp). Keep 'xref' for strictly cross-reference stuff;
>
> Sounds good to me. I'll make that change as soon as xref has a
> suitable public interface for that.

I don't understand; this requires deleting things from xref, not adding
to it.

The current implementation of xref-find-regexp uses project-current,
xref-collect-matches, and xref--show-xrefs. 

If you make the implementation of project-find-regexp use xref
facilities, then I understand your comment. I was hoping for more
separation.

I suggest renaming 'xref--show-xrefs' to 'project-show-locations', and
have it take a list of locations, not implicitly call
xref-find-function. Also move all of the location stuff to project; it's
more general than xref.

xref-collect-matches uses grep; it can simply be moved to
project-collect-matches, along with the xref-*grep functions it uses.
The doc string needs to mention subdirs.

-- 
-- Stephe