[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: BTuin
Subject: Re: [PROPOSAL] Builder, a build system integration for Emacs
Date: Mon, 22 May 2023 18:35:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0

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:
 (build-step . configure)
 (project-file . "CMakeLists.txt")
 (working-directory srcdir)
  (release . "cmake" "-G" "Unix Makefiles" builddir)
  (option . "cmake" "-G" "Unix Makefiles" "-DMY_OPTION=yes" buildir))
 (next-step build (make . parallel)))
 (build-step . build)
 (project-file . "Makefile")
 (working-directory builddir)
  (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]