[XviD-devel] [INFO] dev-api-3 merged into CVS_HEAD

[suxen_drol]

hi,

On Sun, 16 Feb 2003 02:17:17 +0100 Edouard Gomez <ed.gomez at free.fr> wrote:
> Changes made in dev-api-3 are rather important and if we only change the
> patch  version  (third number)  then  it will  not  show  how much  XviD
> features changed. I think 1.0.0 is  good even if we have not reached all
> our desired  features. Sometimes it's  important to get  things released
> even if it's not what we expected. There's still time to improve things.

agree. but what i meant to say:
"we're going from 0.9.1 to 1.0.0, so why not call it libxvidcore.so.1.0.0?"

> the while(0) thingy is very simple. You can't use {} because the ; after
> the macro call  will be misinterpreted by some  compilers, so the better
> solution is to  enclose the code in a  do { } while(0) so  the ";" after
> the macro is right for ANSI C compilers.
> 
> The  while(0) is  then  removed by  the  compiler because  it knows  the
> condition is  always false.  At least the  compiler should  perform that
> supression  during optimization.  If it  does not,  that shows  that the
> compiler sucks -> change the compiler :-)

ok. i understand now.

> As i explained you on IRC, this is a pure maintainer task to keep things
> in sync. Moreover as you see, I communicate important changes to CVS
> before applying them so every coder can ask for a delay. All we need is
> good communication among developers.
> 
> As an example, just look at the way i manage having transcode modules in
> sync with both 0.9.x series and dev-api-3. I'm not superman, I just have
> good organization(well this is the visible part of the iceberg).
> 
> Including vfw and dshow will just break that nice OS independency of the
> core. I think xvid_core_ should stay an independent module.

that is a good point.

> Now i won't force my point of  view. We already discussed that on IRC so
> you  know  I'm against  that.  I just  want  to  hear other  developers'
> opinion.

since the new api intends to be forwards/backwards compatible --
future project-synch issues should become non-existant.

actually, i would prefer xvid to house it's own mirror of the transcode
& player xvid modules, within the xvidcore project. while this _is_
redudant, it would make updating them easier in the event of api change.

-- pete; life is like a box of ammo