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

Received on 2005-12-04