[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: running EDE from a file that is not under a project root dir

From: David Engster
Subject: Re: running EDE from a file that is not under a project root dir
Date: Fri, 07 Aug 2015 12:48:55 +0200
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4 (gnu/linux)

Stephen Leake writes:
> David Engster <address@hidden> writes:
>> Stephen Leake writes:
>>> I have heard complaints that "emacs is not like other IDEs". So when I
>>> see _every_ other IDE providing a single global project, it seems
>>> obvious that Emacs should support that as well.
>> The usual way I know is to load some sort of container which contains
>> any number of projects. In Eclipse it's the 'workspace', in Visual
>> Studio it's the 'solution'. Working with many projects at the same time
>> and seamlessly switching between them is what I would consider to be the
>> norm in other IDEs. Everything else would feel exotic to me.
> Ok, it's been a (long) while since I used Eclipse or Visual *; last time
> I did, there was only one active project. My recent experience is
> Arduino (admittedly a very simple environment by design), Android
> Studio, AdaCore GPS.
> In Eclipse and Visual Studio with more than one project open, is the
> "current project" deduced from the current file?


> If so how do they handle the issue of project hierarchy that I raised?

Things like standard headers are simply not associated with any
project. If you open a file like stdio.h, it will be temporarily
associated with currently active project for things like the 'Build'
button. But that's just an ad-hoc thing. Technically, stdio.h is not
part of any project, and in the 'Project' menu, things like 'Build
Project' are greyed out when you select that file.

> I could see identifying the lowest-level project that contains the file
> (ie, the C standard library project contains stdio.h).

System includes should always be treated specially. They do not change
and are at least in C/C++ a special search path (<string.h> vs
"string.h"). Eclipse determines them automatically by asking the
compiler from the configured toolchain. The system include *paths* can
of course change for a project when I switch configurations and choose a
different toolchain (for instance, when I switch from x86 to
PowerPC). This will also change lots of preprocessor symbols, of course,
and Eclipse parses those automatically as well. Semantic does something
similar, but only for plain gcc, unfortunately.

> But that doesn't give me the full search path, because I don't know
> which higher level project the user is working on.
> In Emacs Ada mode, the top level project is the current project; the lower
> level projects are present as far as gprbuild is concerned, but the
> Emacs code doesn't need to know about them. There are still many
> top-level Ada projects that share lower-level code, so if more than one
> top-level project was open, there would not be a one-to-one mapping from
> file to project.
> If Eclipse and Visual Studio are like that, so the collection of
> projects contains only top level projects, then _if_ they have disjoint
> file sets, you can get the project from a file. But that seems unlikely,
> and highly use case dependent.

In Eclipse, you simply cannot share files or folders between projects,
at least not with the same path. You either copy them, or you symlink
them from one project into another. In the latter case, you can open the
same file twice within two different projects, but since they are in
different paths, the associated project is clear.

I'm not exactly sure how it works in VS, as I'm currently on paternal
leave and I don't use it at home... :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]