On Friday 15 February 2008 19:35:56 Ken Moffat wrote: > Will I disagree ? For the book's users, I'm ambivalent about > testsuites - my experience is that they *can* show up serious > breakage. For people who ask for support here, much better that we > tell someone "sorry, your build is broken because..." at an early > stage. That's why I really feel uncertain about the "learning by > building" part of such a short course - much of the learning comes > from making mistakes, learning how to look at what you did (history, > then finding a way to log what happened, then realising you needthe > error messages as well...), and finding solutions. Mainly in a virtualized enviroment. Note, I work heavily with Xen and after about six month I build a very stable system inside a domU, and the system doesn't show any breaking issue. The same I can't say in VMWare and Virtual PC, I have breakages in major distribution instalations, use of software and even network aberrantes errors. It's crutial to test GCC+Binutis+Glibc in ant stage.
> > Certainly, it's useful for a student to learn that the testsuites > work in different ways. But, just because a testsuite passed it > doesn't always mean the build is good. Equally, I see far too many > failures to get worked up about them. I have no experience of > building in a virtual OS, but I think people have seen exotic test > failures in glibc when doing that. And your course has to end up > with a working system or it is pointless. In learning terms, I think important even make the students make litle testsuits to yours applications. Thay can (and will do) make a lot of mistaken in C, and some basic tests on softwares can bring the erros to theirs eyes. Another important lesson in make testsuites is to train in deducing possible enviroments not so obvious, which is a very important knowledge to any programmer or SO designer. I know, your time is not infinite, but do the students do a make test (at least the most important) can initiate the stuff above and show ups importants erros and why the enviroment affects their future programs.. > > As the tutor, you ought to know more than what you teach the > students, so it would be helpful if you run the testsuites during > your preparation. I really think you need to follow the book more > than once, some things only become apparent the second or third time. > I agree. > For the students, it's perhaps useful to understand that package > maintainers have different ideas about the purpose of testsuites, > and the output can vary dramatically between packages. Gcc or > binutils are useful examples, but gcc in particular is very slow to > test. Glibc's test output is fairly impenetrable. I categorise > make as "should all work, and gives you a nice warm feeling", udev as > "should all work, but might have suspect addition, and does it really > tell you a lot?", findutils as "good for showing the instructions > missed something", the current (old) module-init-tools as "how many > tests can you run and say all one of them succeeded?", vim as "WTF?", > perl as "I've got to look through 1500 tests to see which one > failed?". > What can be hard to a newbie is the arcane compile messages throwed to him. In this case the teacher presence is essential and showing to the students how t manage the flow torrent is quiet usefull. > If you have time, it would be good to select a package or two on > which to run the tests. You might even find one where you can look > at the files and explain _how_ the tests run. Heh, I might pay good > money to go on that! Like I said aboce. The great throuble triple (GCC+BINUTULS+GLIBC) is quite essential. Iside this selecting the most simples to start is a good idea IMHO. > > In reality, I think you'll probably have to pre-build chapter 5, > and probably build large parts of chapter 6 between the classroom > sessions, just to get it all done. In this country, we have, or > had, a kid's TV program where they used to make things, with the > catchphrase "here's one I prepared earlier". You might end up doing > the same thing so you can concentrate on what adds value. I agree this too. > > ĸen > -- > das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
