libvisual-devel

[Libvisual-devel] Re: Plans

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

Dear Dennis,

There are plans for CVS repository?
This way we can keep track of development,
and even we can became involved very
easy.


Duilio.

[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.

Re: [Libvisual-devel] Re: Plans

[Dennis S. <sy...@yo...>]

Thanks a lot this is fantastic!, i've got one issue with
the autogen.sh, 

when using --force within the autogen.sh, is --force needed
or can i drop it ? it seems to work fine without it.
(automake 1.4)

automake: unrecognized option -- `--force-missing'
Try `automake --help' for more information.
autoreconf: automake failed with exit status: 2

Regarding infinity with xmms disabled it's working like a charm!
---

I'm kinda busy right now, we're in the middle of a move (again)
so that is being the reason for that.

However I'll try to find some time tomorrow to import libvisual
into sf.net CVS. I also would be REALLY happy if you could
convert libvisual-plugins, libvisual-xmms and libvisual-nebulus
as well! Also I'll fix the extra_dist issues with libvisual
(stupid me!)

How can I add you as a developer to the libvisual project at sf.net ?

Thanks and cheers,
Dennis


On Fri, 2004-06-18 at 19:22 -0300, Duilio Javier Protti wrote:
> >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.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Libvisual-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libvisual-devel

Re: [Libvisual-devel] Re: Plans

[Dennis S. <sy...@yo...>]

I've got my own reposity local but indeed I should move
it to sf.net. Any suggestions how I can easily move a complete
reposity to sf.net or is it best to just re import the source
trees ?

Btw, you'd like to develop on the infinite plugin I assume ? :)


On Thu, 2004-06-17 at 15:52 -0300, Duilio Javier Protti wrote:
> Dear Dennis,
> 
> There are plans for CVS repository?
> This way we can keep track of development,
> and even we can became involved very
> easy.
> 
> 
> Duilio.