[FFmpeg-devel] [PATCH] Speedup make removing implicit rules for makefiles and dependencies (cure for slow "make" in MSYS+MinGW)

[Adam Strzelecki]

M?ns,

> make -d spews out lots of junk.  That's not news.

I wouldn't call that junk. This stuff is actually done by make  
(including file existence checks) and consumes some time. This may be  
neglected on UNIX coz the difference as Ramiro said is not so  
significant (well, invisible on UNIX).

But unfortunately there are people building FFmpeg on Win, it is not  
me (I do cross compile from Mac), but my client's employees want to  
build the project (using FFmpeg) themselves from the scratch on Win  
box. If you have an access Win box, you may check that running "make"  
makes you wait ~1minute or more (depending on box) before actual  
compilation starts just because all those unnecessary stuff you call  
JUNK must pass, and on Win is takes a while (believe me).

If "make -r" does really produce proper build then case is closed,  
discussion is over, and probably one may note somewhere in FFmpeg docs  
that "make -r" could be used as a cure of this slowdown in MinGW.

> If the builtin rules are slowing down make on your system, you can run
> "make -r" to run without them.  Your ugly hacks have no place in our
> makefiles, and they only disable a tiny fraction of the builtin rules
> anyway.

Those builtin rules are slowing all systems at least for a fraction of  
second (this may be neglected), but Win is exception here that makes  
"make" hang for almost a minute (this shouldn't be IMHO neglected).
I won't argue if the patch is pretty or not, because it is NOT :) but  
its intention was to drop most of builtin rules that were clearly  
unnecessary. But I don't really get why I get so negative response  
from you. I know this patch may hurt your eyes, would hurt mine if I  
were you, but you can find such "nasty" hacks for example in Linux  
kernel, committed around 2.6.19 AFAIR. No, I am not an originator of  
them ;P

> But I was curious of this speedup, so I tried it. Building the entire
> tree with previously ccached objects gave no measurable speedup for
> "make", "make -r", and your patch (all went about 4.2 minutes). All
> deviations were inside stddev. This might be because this was running
> under VirtualBox. Building a tree that was already entirely built (so
> only make was run and it didn't compile anything) I got no speedup
> with your patch but "make -r" made the time go from 19s to 2s.

Ramiro,

I just refer to make (Makefile) itself speedup which is visible mostly  
(only?) on Win box, it is not suppose to speedup the whole build  
process or compilation itself.

I kindly ask you guys to note somewhere in Wiki or Docs that the  
project can be compiled with "make -r" then, if it is confirmed to  
work OK and then we can trash the patch of mine.

Thanks,
-- 
Adam Strzelecki | nanoant.com