designing a language agnostic build tool

you what's up gamers I need input on how you would want a build tool to work for you for whatever language you want to support (e.g. do you want rigid project structure enforcement? integration within already existing language ecosystems? editor integrations? verbosity of information it gives you? etc.) because I hate pretty much every build tool(ing) and ecosystem. To get it out of the way now: I'm not going to be hosting anything (i.e. no package servers or remote building, except if they're self-hosted).

make is good enough imo

>>14267 the most important step in build tools imo, is to make them very simple to use, the basic setup for a compiled language should be a up to ~3 clicks/commands or something. but then of course you need to make a way that enables any customization, that would otherwise be possible with things like make, a good example of how simple it should be is something like cargo, you type "cargo init", enter few things like the project name (interactively, not in config file), and then you type in "cargo run", and do any more sophisticated customization in config files. also the build tool in itself (and in dependencies) should be light if you want it to be widely used

Do you hate stack and cargo ? curious why you would hate them

Honestly, I would just want it to be 100% BSD make compatible.

This already exists, and is called scripting imo

I use make for C and C++ or whenever there isn't an existing language-specific build tool. As far as editor and language integrations are concerned, I've found it much easier to get emacs to play nice with some language-specific build tool than it is to get make to play nice with anything that isn't C, C++, or similar. It seems reasonable to me to use a build tool which is taylored to the language you're using if there is a good option available.

Any way I can follow your progress/help, OP? >>14269 How do you do debug vs release builds or changing the compiler flags? For your bigger projects, did you manage to split your makefile into "modules"? How do you deal with variable names? I've got this tool that outputs two+ files (ugh), how do I make make understand this? Can you share code between similar projects? But I'd agree that make is amazing and unbeatable for small/one-off projects. >>14330 I don't understand why ppl think a centralized module store is acceptable. >>23389 I feel like that means that in addition to everything already in my makefile, I also have to script most of make

>>23405 >I don't understand why ppl think a centralized module store is acceptable. It's convenient. But more to the point, why do people think building the same 1000 libraries for every single project is acceptable? Shared objects were solved decades ago ffs.

>23438 >But more to the point, why do people think building the same 1000 libraries for every single project is acceptable? Shared objects were solved decades ago ffs. Shared objects are soykaf, long compile times are worse. The amount of pain that comes from linking in general is infuriating too. On top of that you get issues with different versions of header files still compiling against the library, versions compiled against a different version still running until you run into some ABI compatibility, dependency hell when you need two different versions of a library, all that crap isn't "solved" by shared objects. If you started with the goal of "I want to not have to recompile everything" you wouldn't end up with something that looks much like that. In fact, if compilers were as fast as they could be, there would be no point in having libraries be like this at all. "just copy the library source code" is the best option since it's transparent to the toolchain, just the rust compiler is unacceptably slow, even more so than already unacceptable compile times on e.g. C programs. Not to mention the amount of times people solve problems by deleting intermediate build files in any language. That is to say that compilers being slow is the problem, not the exact way we deal with pretending that they can't be fast and mindlessly continuing paradigms that have no reason to exist. Build systems are part of this problem. We shouldn't need them. We only need them because of deficiencies. Some of these deficiencies are artificial, like "we can't store the whole program in RAM". Other deficiencies include "compilers are slow", which is only the case because it's the status quo really. People get excited about Go's compile times when they're mediocre at best, just because everything else is actively awful. We need a complete paradigm shift in order to escape the hell of make and linking and dependencies and headers. The implicit idea everyone has about How Stuff Works is not inherent to what people want to do.

It should be AI driven >>14269 Make has some serious design problems, I don't remember what though.

>>23450 >Why did the build fail? >well uberMake forgot to build /some/weird/header/file.c because it's never seen a folder structure like that before >time to spend another 2 months training it

I would make the whole interface JSON based

>>23459 christ no. do not want.

>>23405 Yes, different languages have different standard build systems, so to build existing software you'd need to call into whatever it's using. I guess for software going forward, something like make but better is enough.. If the build system deals with the project structure, it should at least have pluggable project structures for different situations, stacks, languages.. You kind of expect to be able to build with ease, and as quickly as possible. But there's a soykafload of things you might want to do in a build process, and those should be well documented and easy to plug into the build file.