[Libvisual-devel] Re: Plans

[Duilio J. P. <dp...@fc...>]

>Any suggestions how I can easily move a complete
>reposity to sf.net or is it best to just re import the source
>trees ?

Is much easier to make an initial import. However,
you must not import the distributed package, you must
init the repository with a subset of the package, without
the cached building-process files and the system/version
dependent macro files.
Let me explain.
I have rebuild your building scripts with autoconf 2.59
and automake 1.8. ChangeLog is like this:
- configure.in renamed to configure.ac (configure.in is
deprecated)
- AC_INIT and AM_INIT_AUTOMAKE macros moved to the new
long form
- now we check for headers:
AC_HEADER_DIRENT
AC_HEADER_STDC
AC_CHECK_HEADERS([fcntl.h stdint.h stdlib.h string.h sys/time.h
unistd.h])
- now we check for functions:
AC_FUNC_MALLOC
AC_FUNC_REALLOC
AC_CHECK_FUNCS([memset sqrt strdup])
- warn if pkg-config is not installed or installed version
is older than 0.14
- removed examples/Makefile and tests/Makefile from AC_OUTPUT
(because their Makefile.in's are not in the distro!
The tests directory doesn't even exists! Probably you have
forgotten to define EXTRA_DIST macro on the corresponding
Makefile.am's on your working directory, so they are not included
on the 'dist' target)
- finally, AM_CFLAGS is used instead of CFLAGS on libvisual/Makefile.am
Ok, what you must submit to the CVS is a clean tree of the package,
but without configure and all the Makefile.in's. How you will obtain
this on a first checkout? Well, all these will be generated by the
autogen.sh script that I send you attached on a private mail.
For this to work autoconf >= 2.57 and automake >= 1.7 are needed.
What you gain here is an autoconf/automake's version independent
repository. Every developer will build your own macros/cached-files,
that matchs the exact autoconf/automake version they have.

Enjoy it!
                                                                                                               
>you'd like to develop on the infinite plugin I assume ? :)

Yes, I want to get involved. In regard of that, if you have some
time please try to compile my plugin with --disable-mmx option
and let me know the results. I really think the problem is the
use of MMX, because XMMS also use it, and as you probably know,
if you have a context switch before to make emms(), you will
trash the processor's float registers. On my system this work
well, but I have to much reports about this problem.

                                                                                                               
Duilio.