[PD-dev] "imports" section of CVS
Hans-Christoph Steiner
hans at eds.org
Sun Mar 19 20:48:27 CET 2006
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
More information about the Pd-dev
mailing list