4 ms·

With years of experience with Scons, I can say quite confidently that I don’t ever want to work with a Turing-complete build system ever again.

eej71 7y ago
Could you elaborate a bit on what got you to that conclusion? That's not meant as a challenge - just curious to get more perspective on your conclusion.
discreteevent 7y ago
Coming from maven I can say the opposite.
- CountSessine 7y ago
  I think this is sort of the creator/maintainer conflict. Creators hate maven because they have their own idea about how their project should be structured and it’s different from maven’s. Maintainers love maven because they inherit a code base with a canonical structure.
  - snuxoll 7y ago
    As a creator I love Maven for that same reason, I appreciate having a defined structure for my project that makes it easy for anybody on a team to pick it up without needing to navigate a build script of arbitrary complexity.
- rumanator 7y ago
  > Coming from maven I can say the opposite. To be fair, maven is in a class of its own with regards of designing a tool that is the worse of both worlds.
jcelerier 7y ago
> I don’t ever want to work with a Turing-complete build system ever again. so do you instead write custom additional executables that may require a cross-compilation step for whenever you have to perform custom pre/postprocessing tasks on your code (e.g. parsing it, etc)
- nickez 7y ago
  And your point is that it would be better to write pre/postprocessing logic in the build system? That sounds like a recipe for disaster and slow build times.
  - jcelerier 7y ago
    > And your point is that it would be better to write pre/postprocessing logic in the build system well, it has to be somewhere and i'd rather write my build configuration in a language instead of N. So yes, that's what I do currently and it causes me exactly zero issues.
- CountSessine 7y ago
  What I would advise is to think carefully about your custom pre-/post-processing tasks in light of how they will affect componentization and reuse. Working with many teams and codebases, it’s been my experience that having a lot of custom code generation or code parsing ties your code to your build system in ways that make it harder to re-use elsewhere, on different platforms or for different products. It also imposes a level of astonishment when analyzing dependencies - libraries that may appear to be largely independent of each other can actually be effectively coupled if one of them has a funky prebuild codegen step that depends on the other. Or coupled to the core build logic and source tree. If you really need the custom build step, and it really needs to be implemented in your build system, I’d encourage you to think about the tools and language you’re using. If you build it, they will come. Don’t be surprised to find out that a good chunk of your business logic winds up in build files rather than what you would typically think of and analyze as your ‘source’.
- simias 7y ago
  I also have had bad experiences with scons and much prefer declarative build systems with options to escape to external executables when you really can't help it. Because the vast majority of the time, you can actually help it. Having friction to using bespoke compilation steps is a feature in my experience, it means that devs will use standard build elements whenever possible and if a problem occurs the "wildcard" external binaries can more easily be probed and reviewed.
malkia 7y ago
That ^^^

eej71 7y ago

Could you elaborate a bit on what got you to that conclusion? That's not meant as a challenge - just curious to get more perspective on your conclusion.

discreteevent 7y ago

Coming from maven I can say the opposite.

CountSessine 7y ago
I think this is sort of the creator/maintainer conflict. Creators hate maven because they have their own idea about how their project should be structured and it’s different from maven’s. Maintainers love maven because they inherit a code base with a canonical structure.
- snuxoll 7y ago
  As a creator I love Maven for that same reason, I appreciate having a defined structure for my project that makes it easy for anybody on a team to pick it up without needing to navigate a build script of arbitrary complexity.
rumanator 7y ago
> Coming from maven I can say the opposite. To be fair, maven is in a class of its own with regards of designing a tool that is the worse of both worlds.

jcelerier 7y ago

> I don’t ever want to work with a Turing-complete build system ever again. so do you instead write custom additional executables that may require a cross-compilation step for whenever you have to perform custom pre/postprocessing tasks on your code (e.g. parsing it, etc)

nickez 7y ago
And your point is that it would be better to write pre/postprocessing logic in the build system? That sounds like a recipe for disaster and slow build times.
- jcelerier 7y ago
  > And your point is that it would be better to write pre/postprocessing logic in the build system well, it has to be somewhere and i'd rather write my build configuration in a language instead of N. So yes, that's what I do currently and it causes me exactly zero issues.
CountSessine 7y ago
What I would advise is to think carefully about your custom pre-/post-processing tasks in light of how they will affect componentization and reuse. Working with many teams and codebases, it’s been my experience that having a lot of custom code generation or code parsing ties your code to your build system in ways that make it harder to re-use elsewhere, on different platforms or for different products. It also imposes a level of astonishment when analyzing dependencies - libraries that may appear to be largely independent of each other can actually be effectively coupled if one of them has a funky prebuild codegen step that depends on the other. Or coupled to the core build logic and source tree. If you really need the custom build step, and it really needs to be implemented in your build system, I’d encourage you to think about the tools and language you’re using. If you build it, they will come. Don’t be surprised to find out that a good chunk of your business logic winds up in build files rather than what you would typically think of and analyze as your ‘source’.
simias 7y ago
I also have had bad experiences with scons and much prefer declarative build systems with options to escape to external executables when you really can't help it. Because the vast majority of the time, you can actually help it. Having friction to using bespoke compilation steps is a feature in my experience, it means that devs will use standard build elements whenever possible and if a problem occurs the "wildcard" external binaries can more easily be probed and reviewed.

malkia 7y ago

That ^^^