Rockbox mail archiveSubject: Re: Makefile cleanup
Re: Makefile cleanup
From: Daniel Stenberg <daniel_at_rockbox.org>
Date: Sun, 4 Dec 2005 20:07:09 +0100 (CET)
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
> * 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/Received on 2005-12-04