[FFmpeg-devel] libavutil simd

Rich Felker dalias
Tue Oct 2 09:59:57 CEST 2007


On Tue, Oct 02, 2007 at 08:12:41AM +0200, Luca Barbato wrote:
> Rich Felker wrote:
> > On Tue, Oct 02, 2007 at 01:38:16AM +0200, Michael Niedermayer wrote:
> >> [...]
> >>>> e.g. if another project builds libav* in-tree like MPlayer does.
> >>> That is an hack by definition...
> >> indeed and i guess a patch would be welcome by diego ...
> >> that is one which calls/uses ffmpeg configure/Makefile i think?
> > 
> > Diego (I think) had a design for a system by which the makefiles in
> > each directory could function either standalone or included from the
> > makefile in the parent directory, allowing non-recursive make and
> > integrating makefiles. If we could get thath together into a nice spec
> > I think it would be a great thing for FFmpeg and MPlayer (and other
> > projects using FFmpeg in-tree as well) to adopt, not just for ease of
> > maintainence but also to popularize the design and hopefully spread it
> > as an alternative to the autosh*t hell of recursive make.
> 
> autotools correctly rebuild things if you do
> 
> git pull/svn co/cvs co/whatever
> 
> make
> 
> our current system just creates a broken binary in the worst case subtly
> broken...

If that's the case it has nothing to do with autosh*t but rather
missing dependency information. I'm sure everyone would welcome
patches to fix the problem.. Regardless, what you said was totally
off-topic since the system I was talking about has perfect
dependencies if done right, no approximation crap..

> > What about providing both as 2 separate functions, and documenting
> > that the forking function will fork? Or better yet, just read
> > /proc/cpuinfo and forget about supporting runtime cpu detection on
> > systems without cpuinfo or equivalent.
> 
> systems w/out have different means to get the same result, so I think we
> could be fine with it.

Okay..

Rich




More information about the ffmpeg-devel mailing list