On Sat, Jul 07, 2012 at 08:54:12AM -0700, Ronald S. Bultje wrote: > On Sat, Jul 7, 2012 at 5:26 AM, Diego Biurrun <[email protected]> wrote: > > On Fri, Jul 06, 2012 at 09:59:50PM -0700, Ronald S. Bultje wrote: > >> On Fri, Jul 6, 2012 at 6:53 PM, Diego Biurrun <[email protected]> wrote: > >> > On Fri, Jul 06, 2012 at 10:33:19AM -0700, Ronald S. Bultje wrote: > >> >> On Fri, Jul 6, 2012 at 10:27 AM, Luca Barbato <[email protected]> > >> >> wrote: > >> >> > On 07/06/2012 07:13 PM, Ronald S. Bultje wrote: > >> >> >> On Wed, Jul 4, 2012 at 2:09 PM, Måns Rullgård <[email protected]> wrote: > >> >> >>> "Ronald S. Bultje" <[email protected]> writes: > >> >> >>>> On Tue, Jul 3, 2012 at 8:14 PM, Ronald S. Bultje > >> >> >>>> <[email protected]> wrote: > >> >> >>>>> From: "Ronald S. Bultje" <[email protected]> > >> >> >>>>> > >> >> >>>>> This allows compiling and running these tests on systems lacking > >> >> >>>>> a built- > >> >> >>>>> in version of getopt(), such as MSVC. > >> >> >>>>> --- > >> >> >>>>> configure | 2 ++ > >> >> >>>>> libavcodec/dct-test.c | 7 +++++ > >> >> >>>>> libavcodec/fft-test.c | 6 ++++ > >> >> >>>>> libavcodec/getopt.c | 84 > >> >> >>>>> +++++++++++++++++++++++++++++++++++++++++++++++++ > >> >> >>>>> 4 files changed, 99 insertions(+) > >> >> >>>>> create mode 100644 libavcodec/getopt.c > >> >> >>>> > >> >> >>>> Ping. > >> >> >>> > >> >> >>> No matter what, a replacement getopt.c does *not* belong in > >> >> >>> libavcodec/ > >> >> >> > >> >> >> So where does it go? Also, ping re: rest of the patch. > >> >> > > >> >> > Ops my email got lost... > >> >> > > >> >> > libavutil probably, is it the only place in which getopt is used? > >> >> > >> >> git says: > >> >> tools/graph2dot.c > >> >> libavcodec/motion-test.c > >> >> libavcodec/fft-test.c > >> >> libavcodec/dct-test.c > >> > > >> > IMO this is not worth the trouble. Test for getopt in configure and > >> > compile those programs conditionally. > >> > >> They're part of fate. > > > > So? Just run the fate tests conditionally as well. > > > >> I don't understand the trouble part. I already did all the effort. > >> What more trouble could there possibly be? Is deciding where to put > >> getopt.c too much trouble? > > > > The trouble is having ever more replacements for basic system functions > > in libav. That creates a maintenance burden going into the future, > > which is in no way worth the gain of running two tests under MSVC. > > It is already written, so there is no burden.
Let me be more explicit then: This patch is rejected. > Libavutil/ sounds ok to me for placement, any other comments (Mans?) > or can I commit it as such? I can also add a new directory called > "libbrokenos/" and place it there if people prefer that. No. Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
