Skip to content

Please stop using non-declarative opaque build "scripts" and stop infecting other emerging programming languages #71022

@safinaskar

Description

@safinaskar

As well as I understand current recommended practice for building is using so-called build "scripts" for all complex cases (code generation etc): https://doc.rust-lang.org/cargo/reference/build-scripts.html .

Build "scripts" are very big design bug. There is well known IT principle: everything that can be made declarative, should be declarative. I will give some links and quotes to prove my point.

First (emphasis is mine):

TeX. A crippled everything-is-a-text-transformation VM. A great back-end with a nightmarish front-end, as far as I can tell. You get neither WYSIWYG nor the ability to mechanically analyze the content (the document is basically code which transforms itself, and transforms itself, and transforms itself, and you can't make any sense of the document without, um, running it). But people do unimaginably hairy things on top of TeX, like LaTeX. You actually have to debug LaTeX documents, and I bet that the best TeX debugger is somewhat worse than the worst C debugger out there

The quote is from http://yosefk.com/blog/fun-at-the-turing-tar-pit.html (Yossi Kreinin is author of well-known C++ FQA http://yosefk.com/c++fqa/index.html ) and I think this article doesn't contain other information relevant to the topic.

Now the next link: https://yosefk.com/blog/code-data-and-interactive-programming.html . Relevant part is from beginning to words "for many purposes, you can't really "understand" what you've parsed without running it, and this is common to all Turing-complete languages".

The next link: https://www.w3.org/DesignIssues/Principles.html from Tim Berners-Lee, creator of World Wide Web, section "Principle of Least Power".

All this especially applies to build configs/scripts, because build configs are simple, compared to big full-featured programs. They can be made declarative, and thus must be made declarative. Various tools such as IDEs should be able to read and understand build configs.

Currently build "scripts" are written in Rust, so one should compile and run them to extract info. This means that, say, some online service which wants to draw some pretty diagram to user (which will describe build graph of some Rust package) should compile and run this build "script". This means that Rust compiler should be installed on this Web server machine. Also this means that this system is hard to make secure in event of malicious build scripts.

So here is my proposal: move as much as possible from build "scripts" to your TOML manifest. Write everything in declarative form. As a last measure resort to executable build "scripts".

Even makefiles are better then your build "scripts". Because they usually conveys to us graph of dependencies without the need to run untrusted arbitrary commands or code.

Even worse you infected other hobby programming languages!!! Today I learned that Zig programming language ( https://ziglang.org/ ) uses something very similar to your build "scripts": https://ziglang.org/#Zig-Build-System . I think Zig authors get this idea from Rust.

So, please stop using non-declarative "scripts" or at least avoid them as much as possible. Or at least say clearly in the docs that this is bad design decision and creators of new languages should not take it to their languages

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions