[PD-dev] "imports" section of CVS

[Hans-Christoph Steiner]

IOhannes m zmoelnig wrote:
> Hans-Christoph Steiner wrote:
> 
>>
>>
>>I don't know the details of how it all works.  But basically you  upload
>>a tarball, and yes, stuff could be dynamically downloaded and  put into
>>a tarball.
>>
>>But that is avoiding the bigger issue, and that is that if we are  going
>>to be tracking dev software, like portaudio V19, almost all of  the devs
>>are going to want to avoid tracking daily changes in those  projects.  I
>>really don't want to have to debug portaudio when I am  trying to debug Pd.
>>
>>Standard practice in this regard is to then "cvs import" the external 
>>dev code into your repository once you get a version that is working 
>>for you.  If a given project was making releases, then we could do 
>>that.  But for something like portaudio V19, there are no releases.
>>
>>Nothing is stopping all y'all from writing this scripting system.  Go 
>>for it.  Just keep the imported code in CVS for the rest of us.
> 
> 
> this is what i use for one of my current projects:
> https://svn.sourceforge.net/svnroot/iem/spatialization/CUBEmixer/trunk/src/libs/Makefile
> 
> you might find it amazing, but it is a pd-application hosted by a
> subversion system (but it used to be CVS) AND it uses some pd-externals,
> which are not in that repository.
> i am not interested in downloading the whole pure-data repository (it is
> already too big) since i need only a few externals. therefore i made
> this little makefile which gets the sources (and even compiles them and
>  installs them to the places where i like (this is: local to the
> application and not system-wide))
> 
> it is very raw but it basically works (thanks to all those pd-external
> developers who do such a great job :-)), the main problem is the
> connectivity to sourceforge.
> 
> the only drawback i see is: when doing a "cvs update" in the cvs-root,
> the imports section will not be automatically updated. you have use an
> extra command (like "make update -C imports") to get any changes in there.

If you just want a couple externals, grab them from the Pd-extended 
binaries.  We need to stop thinking of Pd as lots of separate projects, 
and think of it as a programming platform, like Java.  The strength is 
in the collection of all the code.


> 2 remarks:
> + "Why not use the existing CVS-infrastructure to do just that?" this i
> can live with very well. However, i read this as "Why not use already
> existing CVS-infrastructure (like the portaudio-cvs) instead of doubling
> infrastructure?"; but since my opinion on this topic is already well
> known, i hope that this was the last rant on it.

How do your script/makefile's docs compared to CVS?  Do you want to 
spend time supporting build scripts or writing code?

.hc

> + personally i am rather at a point where i start to think that the
> pd-cvs at sourceforge is just too big; probably it would be good to
> split it into 2 projects, one for main pd-development and another for
> the development of externals.
>  a pd-stdlib could be part of the core pd-cvs; however, writing this
> down, the idea comes to my mind that this might lead to a two-class
> comunity (those who are allowed into the core cvs, and the others who
> are restricted to the externals-cvs), which i would hate to have; so
> it's probably a bad idea.
> 
> 
> mfg.adsr.
> IOhannes