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
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/
