[FFmpeg-devel] [PATCH] Speedup make removing implicit rules for makefiles and dependencies (cure for slow "make" in MSYS+MinGW)
Wed Oct 28 11:36:27 CET 2009
> 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
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
> 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.
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.
Adam Strzelecki | nanoant.com
More information about the ffmpeg-devel