> One question I have been asking to myself is whether and how the > applets irrelevant to a target system should be dealt with: > * disabled at the configuration stage using KConfig dependencies; > * allowed to fail to build if the user chooses them; > * allowed to build successfully with stub functions replacing the > missing calls (a fake mount() function, for instance), but which will > always fail at runtime.
So it's a mix of 1. and 3. I hate build failures, 2. is out of question. For me, 2 is far superior to 3. I hate debugging at run-time that which can be better dealt with at compile time. If it isn't going to run anyway, why even let it build? Looked at another way, with #3 you (as a developer/system provider) have exported YOUR problem to your customer. Not cool. -- Jim _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
