Re: [PATCH] Project out of sources compilation

[Ergus <spacibba@aol.com>]

On Mon, Apr 01, 2024 at 06:09:48PM +0300, Dirk-Jan C. Binnema wrote:
>On Monday Apr 01 2024, Ergus wrote:
>
>> On Mon, Apr 01, 2024 at 10:49:25AM +0300, Dirk-Jan C. Binnema wrote:
>
>>>> I added one method and with that I already support autotools and cmake.
>>>
>>>(would be nice to add "meson" too!)
>>>
>> No problem once the feature will be more advanced I can add it to the
>> project-multi backend in my github...
>
>Great!
>
>For meson support, I found I needed somewhat of a variation on
>`locate-dominating-file' to find the remotest parent directory that has
>a meson.build. Guess it's similar to what's needed for cmake.�
>

Yes in project-multi I only need to add a simple entry like this:

(:type cmake                      // will be meson in your case
  :program "cmake"                 // name of program to build
  :root-hint "CMakeLists.txt"      // the filename to search in the root dir (gets the top most if nested)
  :build-hint "CMakeCache.txt"     // The file to search in the build dir (searches in root and all root's subdirs)
  :project-regex "project[[:blank:]]*([[:blank:]]*\\([[:alnum:]]+\\).+)" // Regex to search the project name in :root-hint
  :compile-command ":program --build ."  // A command pattern to build from build-dir; `:program' will be substituted
)

:project-regex can also be a function.

sadly I don't really have time now to implement another version of the
code needed in project.el... Because there is a part in Dmitry's
comments I don't really know how to manage to support the workflow I
have now...


>>>No immediate opinions on how to implement this, but things I commonly
>>>want in projects:
>>>
>>>- build
>>>- run
>>>- test
>>>- install
>>>- flash
>>>- debug
>>>- clean
>>>
>> Lets start with the one common to all: `build'
>>
>> Some others are difficult to support i.e I have no idea what is
>> `flash'. And makefile based projects may not have a clean target defined.
>
>Yes, these are only useful for _some_ projects; currently I have some
>custom solution to determine the flash command for the current
>project (if any). But I think it'd be nice to somehow attach the
>functionality to the current project.
>
>Note - it'd indeed be hard to automatically guess/determine this for
>some project; in many cases, it would probably require the user to
>configure some project-specific variable to set the commands.
>
>> The install may be also controversial as it may refer to install in the
>> system or create an install directory.
>>
>> And run is complicated because most projects create multiple outputs, so
>> we need to find some kind of standard method to list them in order to at
>> least ask the user in the first call.
>
>As above, some of this might require some project-specific user
>variables.
>
>For comparison e.g. VSCode allows for doing such actions for many
>projects; Emacs can do that as well, but currently it requires quite a
>bit of custom tweaking; I'm just saying it'd be nice to integrate that
>with project.el.
>
>Some .project-locals.el could be useful for this.
>
>> As Dmitry said, the multiple targets may be also difficult to handle
>> with this abstraction either to `build only one' (may require
>> completion in the command manually) or to debug (in order to know
>> which target/executable to debug). I am not saying it is impossible,
>> just that I don't have enough knowledge about all the tools and their
>> support for such commands.
>>
>> Also remember that this only applies to specific backends because vc
>> backends know nothing about this, so the commands need to be defined
>> somehow conditionally in M-x according to the backend... That's very far
>> from my elisp capabilities...
>>
>>>It's possible of course to "multiplex" with the compile-command and put
>>>in a "transient" or something like that; but it'd be nice to handle this
>>>directly across projects; also for adding menu / toolbar commands.
>>>
>>>Guess this is a bit of an open-ended list, so having `project-*-command`
>>>may not to be the best.
>>>
>> Agree here, but I am not a good lisper... so probably Dmitry can bring
>> some advanced elisp feature I am not be aware of that could solve this
>> issue.
>
>Sorry for hi-jacking your useful proposal to propose some more :-)
>
Not need to sorry... is actually good that someone else also cares about
this... ;)

>Kind regards,
>Dirk.
>
>-- 
>Dirk-Jan C. Binnema                  Helsinki, Finland
>e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
>gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036
>