RE: Makefile cleanup
I also noticed that FAAD (and only FAAD) is being made every time there is a significant change in apps/firmware. Is it really needed? (my guess that its referencing some headers it shouldn't have referenced) Anton. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Holmgren Sent: Sunday, December 04, 2005 1:42 PM To: Rockbox development Subject: Makefile cleanup Hi, I've been rummaging around the Makefiles a bit lately (mainly the for codecs) and I've noticed a couple of things that could be improved: * Several codec makefiles contain a rule like this: $(OBJDIR)/codec/%.o: $(APPSDIR)/codecs/codec/%.c But it doesn't match, so the build rule in make.inc is used instead. Thus, all the extra stuff in the $(CC) command of the rule isn't needed and can be removed. It also means that the only thing the rule really adds is allowing for a different echo line. It also means that at least some codecs (e.g., liba52) are built using -O rather than the intended -O2. So, what to do? Correct the rules and remove the uneccessary stuff, or remove the rules completely? * codecs/Makefile creates a dependency file, but it isn't used, afaict. Should it be used or removed completely? * codecs/Makefile define OUTPUT when invoking the codec makefiles. Many of the codec makefiles define OUTPUT too (and to the same value). Clearly, two definitions is one too many, but which should be removed? I'd say the ones in the codec makefiles. * I've found one thing that makes make clean slow on Cygwin: dependency generation. Adding a ifneq ($(MAKECMDGOALS),clean) around each depenecy file include speeds things up. Is it okay if I add this? (After all, there's no point in updating a dependency file that is about to be deleted anyway.) Magnus
Odd button behaviour (continued)
Hi, It seems that no other user has this problem, or they just don't use the daily builds or read the list. I did some additional testing. * it seems that the button behaviour is quite right, just after the unit is turned on. If the unit's been on for about an hour, maybe two (when it's warmed up), the problems as described start: after a short or long keypress on the left/right/up/down/on button, an off event is somehow generated. When constantly pressing other buttons (scroll through lists, etc), the off event doesn't seem to come through. When turning the unit off at that point, and then turning it on again, it triggers an off event just after resuming, so music stops again. The only solution to keep the music playing is to press F2 or F3 after resuming the music, because these are the only places that don't exit at the off button. * at a point like this, I loaded the 2.5 firmware: problems were gone. Turning off and on, thus loading the newer firmware again, made the problems return. So... was it perhaps because it was flashed? No; I then flashed the 2.5 firmware, and still no problem. All the time I made sure the same config file was being used, so no different settings (perhaps apart from some new features). Now I'm using a flashed 2.5 for some time, without problems. * I searched through the commits-since-2.5 for button, but couldn't find anything pointing into this direction. Am I really the only one with such an odd unit? Ronald --- Forwarded message --- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: rockbox Digest, Vol 3, Issue 47 Date: Tue, 29 Nov 2005 05:35:47 +0100 Hi, not sure about what list is best for this post, but my guess is the user list. With the 27-11 daily build, and what I think was the 25-11 daily build, I experience some odd button behaviour. I'm not sure anymore what version I was using before, but I think it was a version just before or just after 2.5. When I turn up the volume, fast forward, rewind or press on, then sometimes the off button is somehow triggered. Sometimes even twice so the unit turns off. If I continuously press the up button, then quickly the down button, then the left/right button to scroll through the file tree, it's not triggered. But when I hold still for some time, say 2 seconds, the music stops. Because of this delay, it feels like a software issue. But it also seems there's a warming up time: it gets worse if the unit gets used longer, this part of it sounds more like a hardware issue. I'm not sure if it's got anything to do with VBR vs. CBR; lately I've been playing many VBR mp3s while before it had been almost 100% CBR. Recognizable? Any ideas? I couldn't make much of the button.c code, if that's where I should be looking. Could this have to do something with the skip-to-next-folder code, activated by a short + long press of a key, since this is the only code having a delay? Ronald
Re: Makefile cleanup
Tony Lenox wrote: I also noticed that FAAD (and only FAAD) is being made every time there is a significant change in apps/firmware. Is it really needed? (my guess that its referencing some headers it shouldn't have referenced) Indeed, it includes config.h, both directly and indirectly. I guess the indirect reference (which is through ../lib/codeclib.h) is intended to allow the use of DEBUGF and LOGF in the codec itself, but I don't think it is used currently. Anyway, that is outside the makefiles... Magnus
Re: Makefile cleanup
On Sun, 4 Dec 2005, Magnus Holmgren wrote: * Several codec makefiles contain a rule like this: $(OBJDIR)/codec/%.o: $(APPSDIR)/codecs/codec/%.c But it doesn't match, so the build rule in make.inc is used instead. Oops. I guess that mistake is mine! Thus, all the extra stuff in the $(CC) command of the rule isn't needed and can be removed. It also means that the only thing the rule really adds is allowing for a different echo line. It also means that at least some codecs (e.g., liba52) are built using -O rather than the intended -O2. So, what to do? Correct the rules and remove the uneccessary stuff, or remove the rules completely? Personally I think we can go with the make.inc rules as long as they work, since it makes the makefiles smaller and it makes less places the compiler is invoked. * codecs/Makefile creates a dependency file, but it isn't used, afaict. Should it be used or removed completely? Without checking the makefiles, I would say that we should make use of the depfile so that proper dependencies are used/dealt with. * codecs/Makefile define OUTPUT when invoking the codec makefiles. Many of the codec makefiles define OUTPUT too (and to the same value). Clearly, two definitions is one too many, but which should be removed? I'd say the ones in the codec makefiles. I'd say so too. I believe they are mere leftovers from one of my latest cleanups and I probably just didn't clean up everything I should've. * I've found one thing that makes make clean slow on Cygwin: dependency generation. Adding a ifneq ($(MAKECMDGOALS),clean) around each depenecy file include speeds things up. Is it okay if I add this? (After all, there's no point in updating a dependency file that is about to be deleted anyway.) I always knew it did that, but this solution never occurred to me. I'm fine with adding it! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
