4 ms·

Looks conceptually quite similar to make, or did I miss something? Did you use other build systems like e.g. cmake, meson or gn? What makes beast more usable or

by Rochus 4y ago

Looks conceptually quite similar to make, or did I miss something? Did you use other build systems like e.g. cmake, meson or gn? What makes beast more usable or faster than e.g. meson? What always amazes me: shouldn't the build system itself be as easy as possible to build (low requirements on the compiler, minimal dependencies, platform agnostic, etc.), e.g. just like "gcc -O2 buildsystem.c"? Also almost all of these systems seem to suffer from the same problems that were discussed (and solved) in the early years of software engineering, and e.g. hardly support modularization/encapsulation or static type checking. Cmake and meson are huge and complex, with a peculiar dynamic language each, not easy to install and use, and usually a factor ten bigger than what I want to build; also beast itself requires make, a recent gcc version and even flex and bison (so it doesn't e.g. run on windows, does it?).

rjsw 4y ago
The ultimate build system should be written in a language with no implementations at all, failing this it should only be buildable using itself, examples of best practice being Bazel and Gradle /s.
- Rochus 4y ago
  Well, you can expect that there is at least a compiler and runtime available compatible with the software you want to build; if your software is e.g. written in Java, then a build system also implemented in Java looks like a good fit. I usually develop in C++, so my preferred approach is to have a lean build system written in C89 which has only standard dependencies and compiles like "gcc buildsystem.c". I don't know how you would write and deploy a build system when there is no implementation for the language it uses; this looks like an unsolvable bootstrap problem to me; you would need a precompiled build system to build the build system, and that on all platforms you want to build; and anyway I don't think that a build system language should be Turing complete (or otherwise the language should at least support modularization and static typing). Bazel is certainly great for a lot of use cases, but it is one of those Google colossi where you have to hire a specialized team to manage and run your build. GN has a similar issue in that in practice there is an insurmountable dependency of a gazillion of Python scripts (depot tools and the like), even if GN and Ninja are written in C++ and only have standard dependencies.
JonChesterfield 4y ago
Agreed. Essentially the build system should do whatever crackpot things it likes to bootstrap with bespoke languages and so forth, but the output should be a single somewhat auditable C file that gets fed to a compiler, not a binary with exciting dependencies on wherever it was built. How sqlite constructs the single source/header pair looks ideal. Various efforts have bundled lua and some libraries into a single C file too. Check in that generated C file and you have trivial 'bootstrap' for everyone else. Ideally have some CI that checks the dev files still generate that exact C file on request.
- Rochus 4y ago
  Lua is even simpler; there is an all.c which simply includes all other c files in a decent order, so you can just type "GCC all.c" resulting in a full Lua vm executable on all platforms. Other projects like e.g. Duktape offer amalgamated c files as you seem to suggest, but these are redundant.
  - JonChesterfield 4y ago
    This sounded wrong so I checked. You're correct. Current GitHub has a file onelua.c from three years ago. Turns out I forked the project four years ago. Slightly different implementation in that I expanded the #includes to get a single file I can copy around and hacked in a few libraries (libuv, lfs and penlight iirc). Not totally pleased to discover that was so long ago. Great to see that cc onelua.c gets the job done today.
    - Rochus 4y ago
      A file called all.c is also present in Lua 5.1 from 2006 in the etc subdirectory.
      - JonChesterfield 4y ago
        Could be? https://github.com/lua/lua https://github.com/lua/lua doesn't seem to have an /etc subdirectory and I think that's where I cloned from. Can totally believe the work had already been done by someone else and I failed to find it.
gaurav1804 4y ago
Hi! You are right in saying that Beast is "conceptually" similar to Make (and Ninja). But it is much faster and much more user-friendly than Make. Second, you are listing tools like cmake and meson. Note that these are NOT build systems but they are META BUILD SYSTEMS. Meta build systems are tools that don't really build your project themselves... instead they rely on tools like Make, Ninja and Beast to build it for you. You must have seen that Cmake emits a Makefile (or Ninja file depending upon your choice). So comparison in speed to meson will not be appropriate. (Let us just call them high level build tools) About your third query... Well Beast is easy enough to compile. If you don't want to compile it, you can directly download the system binaries at https://github.com/GauravDawra/Beast/releases/tag/v1.1.0 https://github.com/GauravDawra/Beast/releases/tag/v1.1.0 I'm currently using Make to compile Beast because I originally compiled it using Make. It will soon move on to CMake. Please note that it is totally OK to use flex and bison. You don't even need them since I have already provided the cpp/h files generated by them on github!
- Rochus 4y ago
  > these are NOT build systems but they are META BUILD SYSTEMS That's technically true, but you could just integrate the Ninja source code into such a meta build system and run it e.g. with a different command line option and then at the latest the attribute "meta" would be no longer relevant. "meta" in this context doesn't actually mean "on a meta level", but just that the tool is a transpiler from a high-level to a low-level build description, instead of a full execution engine. make (in contrast to Ninja) has features for both levels. Personally I would prefer an integrated system, so bootstrapping would not involve two (artificially) separate parts. But as I understand your message is that Beast is rather a Ninja alternative than a Cmake alternative. That's ok, although we already have Ninja and it claims to be a very fast build tool. So in the question we then just replace Cmake/Meson by Ninja. > since I have already provided the cpp/h files generated by them on github! Ok, I see. So it then also runs on Windows? How do you build the tool on Windows? EDIT: actually if you're interested in GN, which has some very good concepts not seen elsewhere, I've written a tool to view and navigate GN source trees, see https://github.com/rochus-keller/GnTools https://github.com/rochus-keller/GnTools. I usually use it with the Dart SDK source tree.

by Rochus 4y ago

rjsw 4y ago

The ultimate build system should be written in a language with no implementations at all, failing this it should only be buildable using itself, examples of best practice being Bazel and Gradle /s.

Rochus 4y ago
Well, you can expect that there is at least a compiler and runtime available compatible with the software you want to build; if your software is e.g. written in Java, then a build system also implemented in Java looks like a good fit. I usually develop in C++, so my preferred approach is to have a lean build system written in C89 which has only standard dependencies and compiles like "gcc buildsystem.c". I don't know how you would write and deploy a build system when there is no implementation for the language it uses; this looks like an unsolvable bootstrap problem to me; you would need a precompiled build system to build the build system, and that on all platforms you want to build; and anyway I don't think that a build system language should be Turing complete (or otherwise the language should at least support modularization and static typing). Bazel is certainly great for a lot of use cases, but it is one of those Google colossi where you have to hire a specialized team to manage and run your build. GN has a similar issue in that in practice there is an insurmountable dependency of a gazillion of Python scripts (depot tools and the like), even if GN and Ninja are written in C++ and only have standard dependencies.

JonChesterfield 4y ago

Agreed. Essentially the build system should do whatever crackpot things it likes to bootstrap with bespoke languages and so forth, but the output should be a single somewhat auditable C file that gets fed to a compiler, not a binary with exciting dependencies on wherever it was built. How sqlite constructs the single source/header pair looks ideal. Various efforts have bundled lua and some libraries into a single C file too. Check in that generated C file and you have trivial 'bootstrap' for everyone else. Ideally have some CI that checks the dev files still generate that exact C file on request.

Rochus 4y ago
Lua is even simpler; there is an all.c which simply includes all other c files in a decent order, so you can just type "GCC all.c" resulting in a full Lua vm executable on all platforms. Other projects like e.g. Duktape offer amalgamated c files as you seem to suggest, but these are redundant.
- JonChesterfield 4y ago
  This sounded wrong so I checked. You're correct. Current GitHub has a file onelua.c from three years ago. Turns out I forked the project four years ago. Slightly different implementation in that I expanded the #includes to get a single file I can copy around and hacked in a few libraries (libuv, lfs and penlight iirc). Not totally pleased to discover that was so long ago. Great to see that cc onelua.c gets the job done today.
  - Rochus 4y ago
    A file called all.c is also present in Lua 5.1 from 2006 in the etc subdirectory.
    - JonChesterfield 4y ago
      Could be? https://github.com/lua/lua https://github.com/lua/lua doesn't seem to have an /etc subdirectory and I think that's where I cloned from. Can totally believe the work had already been done by someone else and I failed to find it.

gaurav1804 4y ago

Hi! You are right in saying that Beast is "conceptually" similar to Make (and Ninja). But it is much faster and much more user-friendly than Make. Second, you are listing tools like cmake and meson. Note that these are NOT build systems but they are META BUILD SYSTEMS. Meta build systems are tools that don't really build your project themselves... instead they rely on tools like Make, Ninja and Beast to build it for you. You must have seen that Cmake emits a Makefile (or Ninja file depending upon your choice). So comparison in speed to meson will not be appropriate. (Let us just call them high level build tools) About your third query... Well Beast is easy enough to compile. If you don't want to compile it, you can directly download the system binaries at https://github.com/GauravDawra/Beast/releases/tag/v1.1.0 https://github.com/GauravDawra/Beast/releases/tag/v1.1.0 I'm currently using Make to compile Beast because I originally compiled it using Make. It will soon move on to CMake. Please note that it is totally OK to use flex and bison. You don't even need them since I have already provided the cpp/h files generated by them on github!

Rochus 4y ago
> these are NOT build systems but they are META BUILD SYSTEMS That's technically true, but you could just integrate the Ninja source code into such a meta build system and run it e.g. with a different command line option and then at the latest the attribute "meta" would be no longer relevant. "meta" in this context doesn't actually mean "on a meta level", but just that the tool is a transpiler from a high-level to a low-level build description, instead of a full execution engine. make (in contrast to Ninja) has features for both levels. Personally I would prefer an integrated system, so bootstrapping would not involve two (artificially) separate parts. But as I understand your message is that Beast is rather a Ninja alternative than a Cmake alternative. That's ok, although we already have Ninja and it claims to be a very fast build tool. So in the question we then just replace Cmake/Meson by Ninja. > since I have already provided the cpp/h files generated by them on github! Ok, I see. So it then also runs on Windows? How do you build the tool on Windows? EDIT: actually if you're interested in GN, which has some very good concepts not seen elsewhere, I've written a tool to view and navigate GN source trees, see https://github.com/rochus-keller/GnTools https://github.com/rochus-keller/GnTools. I usually use it with the Dart SDK source tree.