Re: [PROPOSAL] Builder, a build system integration for Emacs

["Augustin Chéneau (BTuin)" <btuin@mailo.com>]

Le 21/05/2023 à 21:58, Jim Porter a écrit :
> On 5/21/2023 12:33 PM, Augustin Chéneau (BTuin) wrote:
>> Interestingly I already thought about chaining build systems, but I 
>> wasn't sure how to implement it.
>> Unfortunately the main drawback of your method is that you can't 
>> easily switch between a debug or release mode (if I understood your 
>> code correctly).
> 
> Well, the main reason for that is that I just haven't implemented that 
> yet, since I'd want to go well beyond just a debug/release toggle. For 
> example, this feature could probably be useful for configuring *any* 
> kind of build variant, including things like cross-compilation. I 
> haven't figured out a sufficiently-generic way to handle that across 
> many build systems though.
> 
Oh I didn't mean a simple toggle, I meant an arbitrary command variant. 
For instance with Builder you can define a "debug2", "compile_arm" or 
any other command.

Maybe you could do something like this with Taco:
(cmake
  (build-step . configure)
  (project-file . "CMakeLists.txt")
  (working-directory srcdir)
  (commands
   (release . "cmake" "-G" "Unix Makefiles" builddir)
   (option . "cmake" "-G" "Unix Makefiles" "-DMY_OPTION=yes" buildir))
  (next-step build (make . parallel)))
(make
  (build-step . build)
  (project-file . "Makefile")
  (working-directory builddir)
  (commands
   (default . "make")
   (parallel . "make" "-j4")))

> Currently, the way I tend to use taco is just to let it give me an 
> appropriate template for the compile command, which I hand-edit. For the 
> configuration step, I often add some extra options, but I only need to 
> do that when I'm setting up a build; for actually compiling a project, 
> the default is usually what I want.
> 
>> Also, what if an intermediate step is used in two different context, 
>> both with different next step?
> 
> I think that should be fine. For example, CMake can generate Makefile or 
> Ninja files, depending on what flags you pass. Once it does that, it 
> should be easy to see what the next step is retrospectively by looking 
> at the files in your build dir.
> 
> (This could get a bit trickier for something like meson, which seems to 
> want you to use its own `meson compile` wrapper, even though it uses 
> Ninja as the default build backend. But in that case, I think you'd just 
> need to scan for an appropriate sentinel file for meson in the build 
> dir, and then have the "meson compile step" be higher priority than the 
> generic "Ninja compile step".)
> 
That's why I went with the idea that each build system uses its own 
command to compile, but that's still not ideal as you can't change 
globally the "make" command...


>> I thought of something with a list of targets names, but I'll need to 
>> think more deeply.
>> Currently you could achieve the same manually, but I agree it's not 
>> very convenient.
> 
> This is something I've thought a bit about too: right now, taco is only 
> good for compiling a project, but it doesn't help for things like 
> running unit tests, building HTML documentation, etc. That will take 
> some careful thought though, since some build systems let you define 
> arbitrary build targets for things like this, and others treat targets 
> specially. For example, `make test` is just a normal Make target like 
> any other, but `meson test` is (somewhat) special; I could call my Make 
> "test" target anything I like (e.g. "check"), but I don't think meson is 
> so flexible.
> 
Yes, this is getting complex very quickly.
I think that separating targets is simpler, so you have a known list of 
targets (configure, compile, package, install, test, and run), and you 
can treat each case and build system separately.  The price to pay is a 
lower interoperability between build systems, but I'm not sure if the 
additional complexity worth it anyway.
But I would be interested if you manage to solve it properly!

> Another lower-level option for targets is to take advantage of Emacs' 
> built-in Pcomplete code. Pcomplete can handle completing command-line 
> arguments for lots of commands, and if you added some Pcomplete handlers 
> for "make" that let you tab-complete Make targets, then you could 
> probably use that in Builder (or taco) as well. This has the additional 
> benefit that you get nice tab-completion in M-x shell too.
> 
Nice, thank you!  I wasn't aware of its existence, I'll try it.