Re: [PATCH] Project out of sources compilation

[Mohsin Kaleem <mohkale@kisara.moe>]

Ergus <spacibba@aol.com> writes:

> I'll give it a look. I am aware of cmake presets, but we don't even
> support cmake or out of sources compilation yet, so I tink that
> supporting the most basic cmake setup will be already a step forward.

We being the projects you work on? My suggestion was more for automating
how you set build configurations. Supporting that in Emacs is separate
but still useful. It's just which directory you configure to and build
in is yet another part of this instead of some custom thing only Emacs
understands.

> Yes, that's actually the current approach in my POC code. after some
> fight with rust projects. However, the difference on moving or not is so
> simple that it doesn't even represent a difficulty.

Just moving is easy, but a interface for that that isn't confusing would
probably be a lot harder. For example you can switch to a compilation
buffer and run cd and recompile and that should work. But it's much
easier to just see the command containing the non-common directory it
needs to run in.

> This implies removing many of the features project.el already has
> (project-compile, project-eshell, project-compile-buffer-name-function)
> + somehow create another level of abstraction over project.el...

I think we probably should. There's a lot of builtin Emacs functionality
which is just duplicating standard things in subtly different ways.
project-other-{window,tab}* for example. Embark at least supercedes this
IMO because it generalises the selection backend from the end user
action. In this case project-compile, project-eshell, etc. If this was
being done today I'd probably just define a 'project-run-from-root'
helper and let the end users alias it to a command if they think its
useful. Like so:

  (defalias 'project-compile! (project-run-from-root #'compile))

But I digress.

> The initial basic commands (config, build, test/run) seems to be common,
> even in python projects it usually needs to get dependencies, create
> virtualenvs and so on. However if a project does not support a build
> command a simple message can solve it easily.

I agree, but my point was this doesn't really align with anything else
project.el does atm. Listing files for a project is orthoganal to which
"configure command" makes sense for whatever kind of project this looks
like. And necessarily multiple configure commands may make sense at once.

> FWIK every directory may have a CMakeLists.txt, but they need to have a
> project() entry to be considered a project's CMake. The search is
> actually unavoidable and the regex check actually solves the race
> conditions.
>
> I know that the search is not efficient, but with a couple of
> optimizations if works very well even with tramp.

This aligns with what I know but also that a encompassing CMake with a
project can depend on a sub-directories CMake with a project. So if you
just configure and build the parent project it'll configure and build
all sub-projects. I'm not sure when you'd not want to do this, if the
projects have overlapping targets perhaps... but at that point you
should probably just move them to independent projects because their
already that.

> Nested projects is something very common these days and supporting them
> in project.el is part of another parallel discussion going on already
> (very slowly btw).

I have yet to encounter any so I'll assume you're right :-).

> More or less the same idea; I use with plist. I think they a bit
> simpler, but the same underground. I tend to avoid eioio because I have
> heard some performance complains (don't know if they are justified) but
> also because plists are somehow more flexible in some aspects.

I haven't noticed any performance issues at least in my limited usage of them.

> Actually I am not trying to do anything so fancy. We cannot go from 0 to
> 100 in a single pass. If we start 1. recognizing projects backends and
> giving a better compile-command for them in the right place and to the
> right build-dir is a good step forward compared to what we have. Then we
> talk about test and finally we can consider the generate one.

You should probably keep in mind sometimes there's a feed forward
mechanism in these things. CMake for example requires you to setup a
file prior to configuring if you want to introspect about the build
configuration and available targets. It might help to keep this in mind,
in my case I had to add a hook mechanism for all of these commands after
the fact to generate and keep this file in sync.

[1]: https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html

> At the moment project.el only handles one backend at the time. I made a
> simple workaround to extend it a bit, but that is a bit tricky and at
> this point simplicity matters. Otherwise we end up with an inefficient
> and complex interface easy to break and hard to make it work.

This is probably another reason this should be orthogonal to project.el.
The project backend is something well defined like a git repo. The
project type backend is whatever arbitrary marker communicates what the
project type is.

-- 
Mohsin Kaleem