On Wed, Jul 12, 2023 at 01:18:26AM +0800, Zhangjin Wu wrote: > > > With the new patchset, it is able to rebuild and rerun everything in several > > > minutes, it may make people very happy to develop nolibc itself and also make > > > people to work on linux with nolibc, especially for developing and testing a > > > new kernel feature ;-) > > > > I doubt it. Rebuilding everything is not what most developers need. What > > they need is to just fix a missing parenthesis that broke the build and > > rebuild the strict minimum, restarting from where they left. And they > > need to be able to figure what caused that "FAILED" output, disassemble > > the output, re-run it manually under qemu-user, rebuild the .c manually > > after copy-pasting the whole command line via "V=1", etc. > > > > It is mainly for a cross arch change, like the _start_c() patchset we > just discuss. This may also happen for every release (not that helpful, > for a new release, a mrproper or distclean may be required). Maybe, but let's focus on fixing what's really annoying before trying to improve things that work. If you find yourself failing to do certain things, annoyed with some flags that are forced on you etc, not finding a way to work with multiple output dirs, these are good reasons for applying changes. But thinking that it will likely be better organized this or that way tends to make us forget what we're relying on and that we might lose by accident. > > Keep in mind that the purpose of a selftest is not to optimize the case > > where it works fine, but to optimize the developer's work when it fails. > > This is something that a lot of people tend to get wrong. They're proud > > of a "make world" that does everything including delivering them pizzas > > to wait for the builds to complete, and they say "hey, impressed?". But > > when someone else reports "I'm getting this strange error I don't > > understand", they can hardly suggest more than "hmmm run make clean, try > > again, or use the same distro as me because it works for me". > > > > Parts of them do want to meet the 'optimize the developer's work when it > fails', for example, new developers may be hard to find a loongarch or > riscv bios, or find a toolchain for the not frequently used > architecture, to avoid introduce many bug reports about "strange errors" > outside of our core functions, perhaps we'd better do these in a nolibc > doc under Documentation/, tell people how to prepare the develop and > test environment of nolibc and how to use nolibc there. Reading the beginning of the sentence made me immediately think that it's what doc is for. You know, if you give a fish to a hungry man he eats one day, if you teach him to fish he eats every day. Knowing what to download from where is much more instructive than running "make download" or even worse, "make" and having the downloads secretly succeed (or fail). If you think the doc is hard to find I'm also fine with a patch for makefile and/or nolibc-test passing a pointer to its location as a reminding comment for example. > > And I think that helping the user > > prepare certain steps or iterate over architectures *is* useful. When > > you do it in two layers (the script replacing the user, the makefile > > doing the build job), it remains easy and convenient to use, and you > > can pick only what you need (e.g. "please build musl for me"). And if > > something goes wrong, it's simple for the user to takeover and complete > > that failed task by changing an arch name, a directory or anything, and > > have their tools ready. Let's just never make that automatic for the > > sake of everyone's health! > > Ok, the revision will align with the original Makefile and remove the automatic > parts and no change about the OUTPUT. Just check that you can force it from your script on the make command line. If you see that it's not possible, we should do something because I don't want to force you to make distclean all the time if not needed. But if you find that passing certain options (O=, OUTPUT= or anything else) does the job, it only needs to be documented. Thanks, Willy
