[PD-dev] CVS to SVN ?

[Hans-Christoph Steiner]

I think we are in agreement with that the CVS should be a place to  
gather things too, these things are not mutually exclusive.  I don't  
see any substantial advantage to maintaining parallel build systems.   
I think ideally, there would be a common build system, so that people  
can just plug their stuff into it and not have to worry about writing  
their own build system, porting to various platforms, etc.

The Pd-extended build system does this to some degree, but definitely  
could be improved a lot.  Currently if you want to build just one  
section using a common build system, say sigpack, you can do this:

cvs co pd externals/Makefile externals/sigpack packages/ 
Makefile.buildlayout
cd externals
make sigpack && make sigpack_install

or this:

cvs co pd externals/Makefile externals/sigpack packages/ 
Makefile.buildlayout
cd externals/sigpack
make && make install

As for using svn:externals for reorganizing build systems, that seems  
to just be creating more work for each custom distro.  I think this  
would be much better handled using a common autoconf system, so you  
could do something like:

cd externals
./configure --disable-all-externals --enable-iemmatrix --enable-zexy
make && make install

Then you'd get a custom build of the whole thing with no SVN trickery  
needed.

.hc


On Jan 1, 2008, at 8:02 AM, Winfried Ritsch wrote:

> Hello,
>
>> I've always thought of the pure-data CVS as a place where developers
>> work together on code as a common platform.  People who want to be
>> independent can easily make their own repositories, like Gem, PDP,
>> grill, etc.  Then for Pd-extended, releases of code that is in other
>> repositories can be imported into pure-data CVS.
>>
>
> I always thought of the pure-data CVS as a market place where  
> everyone can put
> their open source projects like libraries of externals, so a user  
> can find
> them there und do not need to make a own web presence and CVS/SVN  
> and also
> make it easier to make an extend release or for everyone to build  
> their own
> extended version of pd.
>
> This is why we put the iem-libs in there and not in the IEM-Opensource
> http://sourceforge.net/projects/iem repositories. The problem that  
> every
> developper change the source if we cant react in an proper time was  
> because
> we trust in other developers unlike some other projects like PDP,  
> grill or
> GEM...
>
>> A lot of libraries are no longer released separately from Pd-
>> extended, so it is something of a standard platform.  There isn't
>> anything else like it, so it's the defacto standard at least.
>>
> But they are still in CVS so they are released as head and if  
> somebody need
> it,  it can be fixed if something is broken, so these libraries   
> are in my
> opinion not dependent on "pd extended".
>
> BTW, I also like to state, that I prefer as less dependencies from  
> one project
> on another if not depended on shared resources other than build  
> systems, eg.
> Makefiles in the parent is really a mess to include this externals  
> in a
> project.
>
> I think, if we solve this problem the decision of how to organize  
> the code
> will be clear.
>
>
> mfg Winfried Ritsch
>
> PS: Who askes the developer on sf on transition. I have no admin  
> rights until
> now, so I think someone from the admins should do the job.
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev



------------------------------------------------------------------------ 
----

As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously.         - Benjamin Franklin