On 1/14/20 4:46 PM, Jody Bruchon wrote: > The tools patch and diff make sense to include because they're simple > text manipulation utilities that can be handy in embedded > environments. "Make" and similar programs are universally meant to be > a component of a compilation toolchain, something which is well > outside the scope of BusyBox.
diff and patch are universally meant to be a component of a source code development, distribution, and compilation toolchain. Just like make. Sure, you could use all three of them for other purposes, and many do. make is pretty easily (ab)used for all sorts of things, diff/patch less so (I use diff for crude revision comparison of prose text in addition to source code, patch could be used to binary patch updates??? but you could also use xxd, assuming you made busybox xxd support some common options that actually allow this). I'd consider it just as reasonable to remove the diff and patch applets as to add a make applet, and I'm not strongly attached to either approach. At least "it's exclusively intended to be useful in a development environment" is a useful objection to inclusion, which I could get behind. The problem is that this is currently not the case... > Anything that's complex beyond a > certain arbitrary point doesn't belong in BusyBox. That's why > Dropbear (ssh), Perl, Python, Lua, Git, and several other extremely > common programs are not present, despite the fact that their presence > might be useful to some people. If you need make, build GNU make and > distribute it alongside the BusyBox binary. Same for your favorite > programming or scripting language. It's not hard to do. This is not even remotely comparable... there are brutally obvious reasons not to include a program that represents an actively-developed moving target, which all of these are except for dropbear, because by definition they become useless or no longer work after a couple of years unless you constantly track upstream. Moreso for a programming language like python, which documents the availability of a GUI windowing toolkit... Moreso given that the standard perl distribution on my system is 56 MB, and python is 151.84 MB. It is possible to build python implementations for embedded systems which are much smaller (micropython), but those are also useless for average use, because they implement the syntax without the stdlib. It also froze the language. So any scripts you write for this have to be targeted specifically to the implementation, and are not cross-compatible with the mainstream language. This is approximately what you can expect of trying to embed a giant programming language. perl supposedly has microperl as something you can build from the official source distribution, but its goal seems to be "test perl with minimal configurations as a single executable", which doesn't necessarily translate to size efficiency, and also it's one person's toy which doesn't actually build, so RIP. That would be the other approach to trying to embed a giant programming language. > A lot of people seem to think that there's zero penalty for including > another program in something like BusyBox. I question the knowledge > level of such people, because anyone who touches any remotely sizable > programming project will quickly see that isolating portions is > nearly impossible. Whenever you add an applet and there's a problem > with it, someone has to fix it. If the maintainer decides to update > the internal interfaces for something like getopt, then every applet > has to be updated to fit that new interface, including your mim/make > applet. There are maintenance and fix chores that will force other > people to poke at your applet. You do not incur zero penalty for > adding it to BusyBox. If you'd get off your high horse for a second, no one has suggested that. Although, personally, I did suggest that disabling it by default would produce a "zero-byte installation footprint penalty" for people who don't want to enable it. Have we somehow gone from claims of a zero-byte installation footprint penalty to claims of "if you add this code, you can then forget it forever and ever, and never edit the source code", without me noticing? Your argument boils down to "code adds complexity, therefore never add new code". It's not a new argument. This is why *any* new applet, including any proposed "make" applet, would be potentially "worth considering", not "the idea is so utterly ludicrous how dare you even think about mentioning it". Consideration, obviously, involves considering. For example, considering how maintainable it is, how much additional code it requires adding, and how useful it might be. It's certainly possible the answer to all these are "not very", "too much", and "not really". But I'm skeptical the answer is "you're a moron for even asking, go away". > The bottom line is that Make programs are a type of program that very > clearly do not belong in BusyBox for philosophical and scope reasons, I don't see either the philosophical or scope reason with any clarity, if your python comparison was meant to prove this then it was a miserable flop. Personally, I'd rather this thread discuss whether a make implementation is suitable for inclusion, instead of "please include my useless boutique mim.sh shellscript which does things specialized to my personal needs and I just invented today". -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User
Description: OpenPGP digital signature
_______________________________________________ busybox mailing list email@example.com http://lists.busybox.net/mailman/listinfo/busybox