[FFmpeg-devel] [RFC] Split libavformat

[Michael Niedermayer]

On Fri, Dec 07, 2007 at 12:56:50AM +0100, Diego Biurrun wrote:
> On Wed, Nov 28, 2007 at 02:03:33AM +0100, Michael Niedermayer wrote:
> > On Wed, Nov 28, 2007 at 01:01:22AM +0100, Diego Biurrun wrote:
> > > On Tue, Nov 27, 2007 at 06:46:56PM +0100, Michael Niedermayer wrote:
> > > > On Tue, Nov 27, 2007 at 04:24:08PM +0100, Diego Biurrun wrote:
> > > > > On Tue, Nov 27, 2007 at 04:21:04PM +0100, Luca Abeni wrote:
> > > > > > 
> > > > > > Ronald S. Bultje wrote:
> > > > > > >> Anyway, for the moment the only ffmpeg code that should be moved to
> > > > > > >> libossupport
> > > > > > >> is libavformat/os_support.* (and maybe some part of network.h?), right?
> > > > > > > 
> > > > > > > I think the question is: do we need/want libossupport?
> > > > > > 
> > > > > > I think yes, unless we want to cause big regressions for some OSs...
> > > > > 
> > > > > I don't think FFmpeg should enter into the operating system business.
> > > > 
> > > > if you want ffmpeg to be useable only on linux then i think you should
> > > > remove yourself from the list of people who have write access to ffmpeg
> > > > svn
> > > > its definitly not my intent to make ffmpeg run only on 1-3 Platforms
> > > > for no reason beyond that we can
> > > > also i dont think our users or the other developers want that ...
> > > > 
> > > > if support requires changes which would lead to less readable or harder
> > > > to maintain code (VC++ for example) droping that is fine
> > > > 
> > > > but arguing that the code doesnt belong into lavf and then arguing that
> > > > we should not create a proper place for such code is very unprofessional
> > > > and egoistic
> > > 
> > > I never said anything remotely similar to what you imply.
> > 
> > well you definitly did remove various OS related hacks from lavf, and it
> > didnt seem like you were in favor of moving them somewhere else, if that isnt
> > so then iam sorry for the missunderstanding
> 
[...]
> I have cleaned up much of the build system and preprocessor directives
> to be more, not less, portable.
[...]
> 
> Last not least I am the one reviewing and committing most build system
> patches, many of which are related to platform support.
> 
> So all in all being suspected of not caring about portability is
> patently absurd.  The contrary is the case.

i never said that you didnt care about portability nor that you wouldnt
have improved portability or not done an excelent and much needed job at
maintaining the build system ...

i just claimed that you removed or were generally in favor of removial
of messy code even if that caused less portability
and it seemed to me due to your comment:
---
> > > > > > > I think the question is: do we need/want libossupport?
> > > > > > 
> > > > > > I think yes, unless we want to cause big regressions for some OSs...
> > > > > 
> > > > > I don't think FFmpeg should enter into the operating system business.
---
that you were against (a libossupport) solving the problem but i now know
that i have missunderstood what you said

so i belive there is nothing we disagree about, and ive just missuderstood
you, and used some somewhat inflamatory choice of wording


> 
> That said, I don't think that the best strategy for portability is to
> add missing pieces for certain systems to every program.  Instead those
> missing pieces should be added to the system directly, even if this is a
> little harder to achieve.  Short term pain, long term gain.

yes, it seems we agree everywhere
* no mess in libav*
* OS/platform should be fixed to be POSIX, ISO C ... compliant
* duplicating hacks of OSs in every application is bad

whats left are OSs which just wont be fixed ...
for these and until the others are fixed, libossupport can provide missing
stuff, its not a duplication per app but rather factorizing this duplication
out into a seperate lib which could be used by (m)any applications


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071207/1850b79a/attachment.pgp>