6 ms·

I'm beginning to think that build scripts should be written in the language they are building, or a more expressive language. So many seem to go in the other di

I'm beginning to think that build scripts should be written in the language they are building, or a more expressive language. So many seem to go in the other direction.

flukus 10y ago
I disagree. The worst problems I see with build scripts are that they are trying to do too much, create branches/tags of themselves, be environmentally aware, etc. Limited build tools are a good thing.
- quantumhobbit 10y ago
  I really do agree that complexity is the enemy, but people keep shoving complexity into build scripts against better judgment. I've given up and would rather deal with a complex ruby script than a makefile of equal intrinsic complexity.
ashitlerferad 10y ago
I disagree. We need declarative build systems instead so building is auditable and doesn't require arbitrary code execution.
- profquail 10y ago
  Something like plmake then? (plmake is a build system written in prolog) https://github.com/cmungall/plmake https://github.com/cmungall/plmake
  - ashitlerferad 10y ago
    plmake allows arbitrary code execution during the build.
- Annatar 10y ago
  No we don't! GNU Make is exactly what we need; that's pah-lenty declarative in the right hands. All you have to do now is make sure your hands are the right hands. Like buddha said: right mind.
  - ashitlerferad 10y ago
    GNU Make allows arbitrary code execution during the build.
    - TeMPOraL 10y ago
      What's the problem with that, exactly?
    - Annatar 10y ago
      You bet it does, and that's exactly what's needed! What's the problem with that, again?
      - qwertyuiop924 10y ago
        Yep. If you're running it for a build, you're running unprivilaged - chrooted, jailed, or zoned if you want to be really safe - and if you're running it for install, than you trust the software in any case. And because makefiles are fairly transparent, you can check what the install is doing beforehand.
- qwertyuiop924 10y ago
  You actually NEED arbitrary code execution during builds. Allow me to explain... Let's say we have a make format called dmake. It invokes $CC with the specified arguments for each file, and links them together into a binary/so/whatever, putting it into the build directory and cleaning artifacts. Okay. Now say that you start a new project in rust. Well, crap, dmake doesn't work. You have to use rdmake, which is built by different people, and uses a more elegant syntax - which you don't know. Then you write Haskell, and have to use hdmake - which of course is written as a haskell program, using a fancy monad you don't know, and python has to use pydmake, and ruby has to use rbdmake, and scheme has to use sdmake, and lisp has to use ldmake, and asm has to use 60 different dmakes, depending on which asm you're using. Instead, we all use make. Make allows for arbitrary code to be executed, so no matter what programming environment you use, you can use a familiar build tool that everybody knows. Sure, java has Ant, Jelly, Gradle and god knows what else, and node has $NODE_BUILD_SYSTEM_OF_THE_WEEK, but even there, you can still use make. That's the power of generic tools.
  - nickpsecurity 10y ago
    You haven't countered parent's point at all. You could've just as easily said the common, subset of SQL could be implemented extremely different in SQL Server, Oracle, Postgres, etc. Therefore, declarative SQL has no advantages over imperative, C API's for database engines. Funny stuff. Let's try it then. The declarative, build system has a formal spec with types, files, modules, ways of describing their connections, platform-specific definitions, and so on. Enough to cover whatever systems while also being decidable during analysis. There's also a defined ordering of operations on these things kind of like how Prolog has unification or old expert systems had RETE. This spec could even be implemented in a reference implementation in a high-level language & test suite. Then, each implementation you mention, from rdmake to hdmake, is coded and tested against that specification for functional equivalence. We now have a simple DSL for builds that checks them for many errors and automagically handles them on any platform. Might even include versioning with rollback in case anything breaks due to inevitable problems. A higher-assurance version of something like this: https://nixos.org/nixos/about.html https://nixos.org/nixos/about.html Instead, we all use make. Make allows for arbitrary code and configurations to be executed, so no matter what configuration problems you have, we can all use a familiar build tool that everybody knows. That's the power of generic, unsafe tools following Worse is Better approach. Gives us great threads like this. :)
hornetblack 10y ago
I've written build scripts in Rust. I take's flippin' forever (relative to shell or make). But at least it has proper error checking. One of the guys working on Redox OS make a library called cake which provides macros for a Makefile style script: https://github.com/ticki/cake https://github.com/ticki/cake
- nickpsecurity 10y ago
  That looks nice. It combines strong, static analysis with simple DSL and underlying power in language if necessary. Looks like The Right Thing approach in action.

I'm beginning to think that build scripts should be written in the language they are building, or a more expressive language. So many seem to go in the other direction.

flukus 10y ago

I disagree. The worst problems I see with build scripts are that they are trying to do too much, create branches/tags of themselves, be environmentally aware, etc. Limited build tools are a good thing.

quantumhobbit 10y ago
I really do agree that complexity is the enemy, but people keep shoving complexity into build scripts against better judgment. I've given up and would rather deal with a complex ruby script than a makefile of equal intrinsic complexity.

ashitlerferad 10y ago

I disagree. We need declarative build systems instead so building is auditable and doesn't require arbitrary code execution.

profquail 10y ago
Something like plmake then? (plmake is a build system written in prolog) https://github.com/cmungall/plmake https://github.com/cmungall/plmake
- ashitlerferad 10y ago
  plmake allows arbitrary code execution during the build.
Annatar 10y ago
No we don't! GNU Make is exactly what we need; that's pah-lenty declarative in the right hands. All you have to do now is make sure your hands are the right hands. Like buddha said: right mind.
- ashitlerferad 10y ago
  GNU Make allows arbitrary code execution during the build.
  - TeMPOraL 10y ago
    What's the problem with that, exactly?
  - Annatar 10y ago
    You bet it does, and that's exactly what's needed! What's the problem with that, again?
    - qwertyuiop924 10y ago
      Yep. If you're running it for a build, you're running unprivilaged - chrooted, jailed, or zoned if you want to be really safe - and if you're running it for install, than you trust the software in any case. And because makefiles are fairly transparent, you can check what the install is doing beforehand.
qwertyuiop924 10y ago
You actually NEED arbitrary code execution during builds. Allow me to explain... Let's say we have a make format called dmake. It invokes $CC with the specified arguments for each file, and links them together into a binary/so/whatever, putting it into the build directory and cleaning artifacts. Okay. Now say that you start a new project in rust. Well, crap, dmake doesn't work. You have to use rdmake, which is built by different people, and uses a more elegant syntax - which you don't know. Then you write Haskell, and have to use hdmake - which of course is written as a haskell program, using a fancy monad you don't know, and python has to use pydmake, and ruby has to use rbdmake, and scheme has to use sdmake, and lisp has to use ldmake, and asm has to use 60 different dmakes, depending on which asm you're using. Instead, we all use make. Make allows for arbitrary code to be executed, so no matter what programming environment you use, you can use a familiar build tool that everybody knows. Sure, java has Ant, Jelly, Gradle and god knows what else, and node has $NODE_BUILD_SYSTEM_OF_THE_WEEK, but even there, you can still use make. That's the power of generic tools.
- nickpsecurity 10y ago
  You haven't countered parent's point at all. You could've just as easily said the common, subset of SQL could be implemented extremely different in SQL Server, Oracle, Postgres, etc. Therefore, declarative SQL has no advantages over imperative, C API's for database engines. Funny stuff. Let's try it then. The declarative, build system has a formal spec with types, files, modules, ways of describing their connections, platform-specific definitions, and so on. Enough to cover whatever systems while also being decidable during analysis. There's also a defined ordering of operations on these things kind of like how Prolog has unification or old expert systems had RETE. This spec could even be implemented in a reference implementation in a high-level language & test suite. Then, each implementation you mention, from rdmake to hdmake, is coded and tested against that specification for functional equivalence. We now have a simple DSL for builds that checks them for many errors and automagically handles them on any platform. Might even include versioning with rollback in case anything breaks due to inevitable problems. A higher-assurance version of something like this: https://nixos.org/nixos/about.html https://nixos.org/nixos/about.html Instead, we all use make. Make allows for arbitrary code and configurations to be executed, so no matter what configuration problems you have, we can all use a familiar build tool that everybody knows. That's the power of generic, unsafe tools following Worse is Better approach. Gives us great threads like this. :)

hornetblack 10y ago

I've written build scripts in Rust. I take's flippin' forever (relative to shell or make). But at least it has proper error checking. One of the guys working on Redox OS make a library called cake which provides macros for a Makefile style script: https://github.com/ticki/cake https://github.com/ticki/cake

nickpsecurity 10y ago
That looks nice. It combines strong, static analysis with simple DSL and underlying power in language if necessary. Looks like The Right Thing approach in action.