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/l...
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