[FFmpeg-devel] [PATCH] dct-test compile fix

[Jacob Meuser]

On Tue, Jun 24, 2008 at 11:25:14PM +0100, M?ns Rullg?rd wrote:
> Jacob Meuser <jakemsr at sdf.lonestar.org> writes:
> 
> > On Tue, Jun 24, 2008 at 10:20:56PM +0100, M?ns Rullg?rd wrote:
> >> "Ronald S. Bultje" <rsbultje at gmail.com> writes:
> >> 
> >> > Hi Diego,
> >> >
> >> > On Tue, Jun 24, 2008 at 4:23 PM, Diego Biurrun <diego at biurrun.de> wrote:
> >> >> Are you still using your port of our build system to autoconf that
> >> >> manages to cram less features into more lines of code? ;-p
> >> >
> >> > As long as no proper make dist and distcheck replacements exist such
> >> > that it allows me to integrate it with 0 (zero) lines of (build) code
> >> > into any project that I base on ffmpeg: yes.
> >> >
> >> > (Actually, it's 2 lines of build code: I need
> >> > AC_CONFIG_SUBDIRS(ffmpeg) in my configure.ac and a SUBDIRS=ffmpeg in
> >> > the toplevel Makefile.am. Try beating that. :-).)
> >> 
> >> The fallacy here is in the use of autoconf at all.  If the outer
> >> package didn't use autoconf, interfacing to FFmpeg's configure would
> >> be trivial.
> >
> > meh.
> >
> > I had to hack ffmpeg's build process more than most autotools
> > using projects to get ffmpeg to build and work on OpenBSD ...
> 
> A lot of the trouble there is OpenBSD lacking POSIX-compliant tools.

somewhat.  but then again, I've ported many multimedia (and other)
applications and this is he first time I've run into the need for
'nm -P' or 'od -A'.

> > including removal of some of the explicit OpenBSD support in the
> > configure script which has bit-rotted to the breaking point
> > (hint: shared library names).
> 
> Feel free to send patches.  Autoconf also requires continuous updates,
> and new versions are rarely fully backwards compatible.
> 
> > autotools may be far less than ideal, but they are more or less
> > standard.  this has serious benefits that homegrown build systems
> > will never achieve.
> >
> > well, at least you're only (ab)using GNU make as opposed to
> > say scons (shudder).
> 
> POSIX make is useless, so we have to use something else.  Since GNU
> make is widely available, and has the required functionality, we chose
> to use it.

sure, but I don't think POSIX make is useless.  I mean, the autotools
do not rely on GNU extensions to make.

> > and no, I'm not going to send my patches back to you because
> 
> With that statement, you gave up your rights to complain if our build
> system doesn't work on your machine.

so how should I "fix" the issues with nm and od, for example?

I have asked other OpenBSD developers about them.  no one (including
myself) is interested in adding this stuff just for the sake of
ffmpeg's build process, especially since they can be worked around
fairly easily.

> -- 
> M?ns Rullg?rd
> mans at mansr.com
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

-- 
jakemsr at sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org