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

[Edouard Gomez]

suxen_drol (suxen_drol at hotmail.com) wrote:
> we're going from 0.9.1 to 1.0.0?

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.

> i have performed my own comparison, and CVS_HEAD is identical to the
> dev-branch, except for some minor portab.h issues:
> 
> * we nolonger need the EMMS() macro

Yep, i forgot that dev-api-3 change. Will be merged

> * there are snprintf macros for MSVC

I  trust you  because i  don't know  how win32  stuff works  :)  Will be
merged.

> * the linux DPRINTF has been macro. though it is wrapped in a while(0)
> loop, which is rather odd. anyone know why?

I refuse  that one because  the MacOSX port  needs this DPRINTF to  be a
function for  variable parameters passing. However I've  read a document
this afternoon (MacOSX porting guidelines). And it seems that i can come
back to the macro version for all *nix platforms.

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 :-)
 
> another related issue, is the vfw and dshow project. we need to merge
> the dev-api-3 versions of these, back into their individual CVS_HEAD's.
> this is painfull; i'd rather have vfw and dshow inside the xvidcore
> project, such that everything is in sync.
> 
> prime example: people who checkout CVS_HEAD of xvidcore,vfw,dshow TODAY
> will find they're incompatible.

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.

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.

-- 
Edouard Gomez-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030216/4382765a/attachment.bin