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

[Måns Rullgård]

Jacob Meuser <jakemsr at sdf.lonestar.org> writes:

> 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'.

That's hardly a valid excuse.

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

Strictly speaking, yes.  However, autoconf/automake does all the work
that a proper make would do in the configure script instead, and does
it poorly.  The result is a configure script and makefiles 1<<INT_MAX
times bigger than necessary, and correspondingly longer build times.

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

Do what everybody else seems to have done: add support for the
standard flags.

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

Fine, it seems that nobody is interested in OpenBSD being used.  I'm
certainly not going out of my way to accommodate a rotting OS whose
developers refuse to make a minimal effort to keep it up to date with
modern standards.  It's your choice, either you follow standards and
enjoy plenty of software without hassle, or you do it your way, and
waste time "porting" programs.

-- 
M?ns Rullg?rd
mans at mansr.com