3 ms·

Why are you swallowing "error" from invoking the "reall" tool? That seems like a great way to make contributors really frustrated: https://github.com/impervious

Why are you swallowing "error" from invoking the "reall" tool? That seems like a great way to make contributors really frustrated: https://github.com/imperviousinc/beacon/blob/main/tools/src/butil/main.go#L54 https://github.com/imperviousinc/beacon/blob/main/tools/src/... and again https://github.com/imperviousinc/beacon/blob/main/tools/src/realbutil/main.go#L123 https://github.com/imperviousinc/beacon/blob/main/tools/src/... This trend of "I'm going to invent some build tool because there are not enough build tools in the world" is evidently leaking out of the node ecosystem For clarity, I did see that this was inspired by the brave-browser model, but of the ones to draw inspiration from, that's for sure not it given that their CI is closed source and they're trying to use npm in lieu of a more structured, comprehensible system I like trying out alternate browsers, so congratulations on the launch, and I'll for sure try to build it, but I wanted to draw these to your attention because my experience with software is that error handling is about 80% of the job

buffrr 5y ago
> Why are you swallowing "error" from invoking the "reall" tool? That seems like a great way to make contributors really frustrated Glad you're looking at the code! There's still some refactoring needed for butil. It will get more polished soon ;) > This trend of "I'm going to invent some build tool because there are not enough build tools in the world" is evidently leaking out of the node ecosystem butil applies string replacements, patches and overrides all under one tool using a statically typed language but still usable like a scripting lang since it can rebuild the actual tool as needed. You can technically do something similar with various python scripts I suppose and use chromium's GN build system . GN would just end up calling various scripts so I think i prefer this more unless you have some other ideas.
- mdaniel 5y ago
  It may be "statically typed" but from a consumer's PoV, 100% opaque. My first question when trying to build any project is "what is this going to do to my machine" and with some golang based build system, you're asking for a lot of trust on two different levels: 1. go install something (so now I need to read its source) 2. oh, turns out it actually delegates to an entirely separate binary that I now need to separately read And I hear you about "but scripting!!1", however, using one of the existing tools means there is a non-zero chance of someone having experience with them and maybe even having reasonable editor support for it It's your project, so I know I'm just some rando on the Internet, but I wanted to make sure you were choosing the contribution path you wanted to build upon, and not just hacking something together for expedience that then has to be unwound later. In this specific case, that goes double because it already has tight coupling to GN due to Chromium
  - buffrr 5y ago
    > but I wanted to make sure you were choosing the contribution path you wanted to build upon > that goes double because it already has tight coupling to GN due to Chromium Interesting i'll experiment with moving this to GN. I have more high priority things to deal with atm but i'll get to that.

buffrr 5y ago

> Why are you swallowing "error" from invoking the "reall" tool? That seems like a great way to make contributors really frustrated Glad you're looking at the code! There's still some refactoring needed for butil. It will get more polished soon ;) > This trend of "I'm going to invent some build tool because there are not enough build tools in the world" is evidently leaking out of the node ecosystem butil applies string replacements, patches and overrides all under one tool using a statically typed language but still usable like a scripting lang since it can rebuild the actual tool as needed. You can technically do something similar with various python scripts I suppose and use chromium's GN build system . GN would just end up calling various scripts so I think i prefer this more unless you have some other ideas.

mdaniel 5y ago
It may be "statically typed" but from a consumer's PoV, 100% opaque. My first question when trying to build any project is "what is this going to do to my machine" and with some golang based build system, you're asking for a lot of trust on two different levels: 1. go install something (so now I need to read its source) 2. oh, turns out it actually delegates to an entirely separate binary that I now need to separately read And I hear you about "but scripting!!1", however, using one of the existing tools means there is a non-zero chance of someone having experience with them and maybe even having reasonable editor support for it It's your project, so I know I'm just some rando on the Internet, but I wanted to make sure you were choosing the contribution path you wanted to build upon, and not just hacking something together for expedience that then has to be unwound later. In this specific case, that goes double because it already has tight coupling to GN due to Chromium
- buffrr 5y ago
  > but I wanted to make sure you were choosing the contribution path you wanted to build upon > that goes double because it already has tight coupling to GN due to Chromium Interesting i'll experiment with moving this to GN. I have more high priority things to deal with atm but i'll get to that.