On 1/14/20 1:43 PM, Laurent Bercot wrote: >>> - we agree, that "make" will never go into busybox. >> >> Why not? It is useful, and has well-established POSIX >> properties/documentation, there are several other implementations to >> compare and test against, and it can be disabled by default in which >> case it won't add a single byte to anyone's busybox. > > I suggest adding the "c99" utility to busybox. > It's useful, it has well-established POSIX properties and documentation, > there are several other implementations to compare and test against, and > it can be disabled by default in which case it won't add a single byte > to anyone's busybox. > > Surely it's worth at least considering? I'd expect the reason there's no > C compiler applet is very simple: no one has contributed one. If you thought that was humorous... I don't actually see any fundamental problem with that? At least not based on your attempt to turn the argument around. If you're going to humorously insult an idea, your previous "bikeshed" voting applet did a decent job, but you've totally missed the boat here due to not actually conveying any sort of message about why it should be bad.
Although it might be challenging for completely different reasons, that is, to implement e.g. utility libraries (think libtcc1.a, libgcc.a/libgcc_s.so) or headers provided by the compiler/libc in a way that preserves busybox's single-file distributable nature but without baking in assumptions about having an existing gcc/glibc development environment or somesuch. This is not a general condemnation on implementing a busybox binary that you've just arbitrarily decided "shall not be accepted" simply by fiat, without provided rationale and without being the project maintainer who actually has the right to arbitrarily decide things. Creeping featuritis is indeed a problem, but that's why proposals get carefully considered for their utility before being implemented. There must be some reasonable yardstick by which to measure usefulness; being in POSIX and used to bootstrap/compile most operating systems and a fair amount of the userland software seems like a not-unreasonable criteria, much like the inclusion of "cp" because lots of software uses it at runtime. And after all, why include patch and diff applets, then reject make on sheer principled outrage? -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
