Re: Project detection and configuration

[Lluís]

Dmitry Gutov writes:

> On 10/14/2015 06:58 PM, Lluís wrote:
>> * Repository
>> ** Detect the root directory that conforms a checked-out repository
>> ** Ignore repository-specific files on other components
>> ** Interact with repo-management tools?

> You might want to look at lisp/progmodes/project.el in the current master, if
> you haven't already.

I wasn't aware of it, thanks.


>> * Project information
>> ** Name, version, homepage, etc

> I think these are very low priority.

Completely true.


>> * Build system
>> ** This one seems rather tricky to provide a unified interface
>> ** Detect autotools, hand-made makefiles, ant, maven, linux, etc.
>> ** Build modes of a project (e.g., debug vs release)
>> ** Generate files (targets) of a project
>> ** Create release tarballs?

> I'd rather have a flat list of tasks, so that different tasks could do many of
> these things.

> Do we really need to be able to know, programmatically, that a certain task is
> related to the "debug" build? Otherwise, it would simply be to the build tool
> integration to include (or not) "debug" in the returned task name.

Hmmmm, it's not that a task is debug only, but that it's not the same a task in
debug mode than in release mode. For example, you can have a debug and a release
build of the same program, each on its own out-of-tree build
directory. Therefore a make command would differ based on the target *and* the
build mode.

Still, I'm not sure there's a clean way to handle this without hardcoding the
difference between task and build mode. And I'm not even sure this makes sense
on all types of builds.


>> ** Sometimes identifies the root directory of the project

> When it does, a project implementation will have to handle this. Using
> `locate-dominating-file' or `file-exists-p' is not hard.

Right. My point is that using a repository root is a sane default most of the
time, but sometimes it might be necessary to use project-specific information
for that. For example, imagine some linux kernel checkout (which can be properly
identified) that is stored on some sub-directory of a larger repository.

Still, the root directory is not a useful piece of information per se, but it
can be handy to derive other information like paths to look for other files.


Cheers,
  Lluis

-- 
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth