[PD-dev] "imports" section of CVS

[IOhannes m zmoelnig]

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.


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.

+ 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