Re: Project out of sources compilation

[Ergus]

On Sun, Mar 17, 2024 at 10:45:29AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 17 Mar 2024 08:22:56 +0100
> > From: Ergus <spacibba@aol.com>
> >
> > >
> > >project.el has just one, very simple command, where the only thing that it does it 
> > switch to the root first. How will you customize it? With a hook, where the user would write 
> > a function "determine a directory for compilation"? They might as well define a 
> > new command - or redefine this one. Or just an option with relative directory name?
> > >
> >
> > IMO the only thing we need is probably a variable/custom like 
> > project-build-dir. The user can define it in the dir-locals and the project 
> > command will use it if defined/ else use project-root. Maybe the backend could 
> > initialize it.
> >
> > Alternatively (and not totally exclusive) project.el could define a 
> > project-build-dir function that project backends could optionally redefine (i.e 
> > I use a plist as project id in gags-mode and getting any stored property from 
> > there is very easy with a command). By default it will be an alias for 
> > project-root in the VC backend.
>
> Maybe I'm missing something, but isn't the build tree just one more
> tree that is part of the project?  If so, can't you use
> project-external-roots to add this tree to the project?  I thought
> this was the mechanism to add trees to a project as included in the
> original design of project.el and its support in Emacs?

> > There is also some need for a 'bin' dir, that is, where the final executable 
> > will reside, useful to execute and debug with tools like gud and independent 
> > from 'build'...  For example in a python project this may be the project root 
> > OR where the file with __main__ resides, but a python project usually won't 
> > specify a build dir. But let's go for one thing at a time.
>
> Likewise here.
>
> Or what am I missing?

Hi Eli:

More or less we have it, that's why I said that there was just some
(small) missing pieces.

We have the `project-external-roots`, but project.el uses them only to
find files and regexps. So it looks like they are intended to be source
places somehow.

The compile or debug programs doesn't know that they are intended to
execute there.

However, a `build` or `bin` are different because they are where the
`compile` or `gud` are intended to run; generally not a place to search
for sources (unless the source is generated like config.h).

Two examples:

```
git clone emacs
cd emacs
mkdir build # or mybuild, build_debug.. any name
./autogen.sh # (this is intendedto happen in the root)

cd build
../configure options  // This creates a Makefile
make

make install
```

On cmake

```
git clone project
cd project

  // Creates a CMakeCache.txt
  Alternative 1
    cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=true -DCMAKE_BUILD_TYPE=Debug -B 
build/
    cd build

  Alternative 2
    mkdir build
    cd build
    cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=true -DCMAKE_BUILD_TYPE=Debug ..

make
make install
```

The pattern is pretty much the same, so it is pretty simple to allow
projects.el to simplify the generation-compilation-execution-debug
workflow. And with autotools+cmake we are probably covering a huge range
of projects around.

Best,
Ergus