After the long winded discussion about whether to import sources in the Pd CVS, I want to propose a comprimise: making an "imports" section of the CVS. Then those who don't want to deal with imported code can just ignore the "imports" section.
But be forewarned Pd-extended on Mac OS X and Windows would then rely on code from the "imports" section, unless you manually redirect things.
Any objections?
.hc
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
After the long winded discussion about whether to import sources in the Pd CVS, I want to propose a comprimise: making an "imports" section of the CVS. Then those who don't want to deal with imported code can just ignore the "imports" section.
But be forewarned Pd-extended on Mac OS X and Windows would then rely on code from the "imports" section, unless you manually redirect things.
Any objections?
I don't have real objections, but could you elaborate a bit on how you intend to rely on the imports sections with Pd-extended and how to redirect things? I would prefer if not-having-to-redirect would be the default, and if the imports section would only be used, if explicitly specified. Or something like that.
Ciao
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
After the long winded discussion about whether to import sources in the Pd CVS, I want to propose a comprimise: making an "imports" section of the CVS. Then those who don't want to deal with imported code can just ignore the "imports" section.
But be forewarned Pd-extended on Mac OS X and Windows would then rely on code from the "imports" section, unless you manually redirect things.
Any objections?
I don't have real objections, but could you elaborate a bit on how you intend to rely on the imports sections with Pd-extended and how to redirect things? I would prefer if not-having-to-redirect would be the default, and if the imports section would only be used, if explicitly specified. Or something like that.
A good example would be the DSSI stuff. The fluidsynth plugin code would be in "imports" and the Windows and Mac OS X parts of the Makefile would include the source code in imports. The GNU/Linux part would look in the standard system locations for that stuff.
.hc
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
A good example would be the DSSI stuff. The fluidsynth plugin code would be in "imports" and the Windows and Mac OS X parts of the Makefile would include the source code in imports. The GNU/Linux part would look in the standard system locations for that stuff.
Well, I guess I misunderstood what should go in imports, and maybe I do have objections: I thought, "imports" was to be intended for libraries, that are required by Pd externals and maybe Pd itself, but not for standalone applications independent from Pd, as the DSSI plugins are? The DSSI folks have their own Sourceforge project, they have their own release system, and their applications are not required to run Pd at all.
I'm still against packaging DSSI, LADSPA or VST plugins with Pd. If the DSSI folks or Steinberg need help to provide binary plugins, then that doesn't concern Pd and thus doesn't belong in the Pd CVS, IMO. Everyone may feel free to give them a hand at ladspa.org or dssi.sf.net but this has got nothing to do with Pd.
Ciao
Well, I guess I misunderstood what should go in imports, and maybe I do have objections: I thought, "imports" was to be intended for libraries, that are required by Pd externals and maybe Pd itself, but not for standalone applications independent from Pd, as the DSSI plugins are? The DSSI folks have their own Sourceforge project, they have their own release system, and their applications are not required
agreed.. the exception is made for portaudio, because while they have no CVS, theres no 'release' in the past few years. afaik 'Audacity' includes portaudio in their tarballs as well (not sure about CVS, as i hate audacity and just saw this on LAU.)
agreed.. the exception is made for portaudio, because while they have no CVS, theres no 'release' in the past few years. afaik 'Audacity' includes portaudio in their tarballs as well (not sure about CVS, as i hate audacity and just saw this on LAU.)
Portaudio has a CVS. Portmidi doesn't have, as far as i know.
best greetings, Thomas
On 13 Mar 2006, at 23:15, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Well, I guess I misunderstood what should go in imports, and maybe I do have objections: I thought, "imports" was to be intended for libraries, that are required by Pd externals and maybe Pd itself, but not for standalone applications independent from Pd, as the DSSI plugins are? The DSSI folks have their own Sourceforge project, they have their own release system, and their applications are not required to run Pd at all.
I don't necessarily agree with that. Perhaps 'imports' isn't the right word, but the fact that a library isn't required to run Pd at all might not be a good enough reason not to include it in an extended build system, especially if it is kept completely apart from the main tree.
I would rather see apt or fink-style dependency resolution, but I think hc's compromise of separating concerns and letting people ignore 'imports' if they want to/need to seems fair enough. I would rather see it built, than stop here on principle.
d -- David Casal Researcher, Department of Computing Goldsmiths College, University of London Office : +44 020 7078 5151 Mob : +44 07803 173959
Hallo, David Plans Casal hat gesagt: // David Plans Casal wrote:
I don't necessarily agree with that. Perhaps 'imports' isn't the right word, but the fact that a library isn't required to run Pd at all might not be a good enough reason not to include it in an extended build system, especially if it is kept completely apart from the main tree.
But we're not talking about libraries here at all, we're talking about complete applications now! Would you consider packaging Pd with Firefox, just because a browser is needed to read the manual? I guess you wouldn't, and not only because Firefox is a huge application, but also because Firefox has a life outside of Pd and because it is useful on many other occasions as well and there's nothing Pd-specific about Firefox.
That is *exactly* the situation with LADSPA, VST or DSSI plugins: They have a seperate life outside of Pd. Pd is just one of a dozen (dssi) or many dozens (LADSPA, VST) host applications for these plugins. If someone wants binary packages of dssi plugin/apps, then instead of putting (and in fact hiding) them in a Pd CVS or in a Pd binary installer package, much more is gained by getting involved with the dssi-team and help them do proper releases for all supported operating systems. But - repeating myself form the umpteenth time - this has nothing to do with Pd.
Ciao
On 14 Mar 2006, at 10:42, Frank Barknecht wrote:
I don't necessarily agree with that. Perhaps 'imports' isn't the right word, but the fact that a library isn't required to run Pd at all might not be a good enough reason not to include it in an extended build system, especially if it is kept completely apart from the main tree.
But we're not talking about libraries here at all, we're talking about complete applications now! Would you consider packaging Pd with Firefox, just because a browser is needed to read the manual? I guess you wouldn't, and not only because Firefox is a huge application, but also because Firefox has a life outside of Pd and because it is useful on many other occasions as well and there's nothing Pd-specific about Firefox.
Ok point taken.
That is *exactly* the situation with LADSPA, VST or DSSI plugins: They have a seperate life outside of Pd. Pd is just one of a dozen (dssi) or many dozens (LADSPA, VST) host applications for these plugins. If someone wants binary packages of dssi plugin/apps, then instead of putting (and in fact hiding) them in a Pd CVS or in a Pd binary installer package, much more is gained by getting involved with the dssi-team and help them do proper releases for all supported operating systems. But - repeating myself form the umpteenth time - this has nothing to do with Pd.
Fine, but I'd like to see what exactly hc wants to put in there, because while I see your point, I also see that there is a dependency problem which he must solve (and no it's not as big as Firefox), and he's pretty much the only person working full time on it, so while maintaining sanity, we need to ease the road for him, not throw obstacles at him if at all possible.
d
-- David Casal Researcher, Department of Computing Goldsmiths College, University of London Office : +44 020 7078 5151 Mob : +44 07803 173959
Hallo, David Plans Casal hat gesagt: // David Plans Casal wrote:
Fine, but I'd like to see what exactly hc wants to put in there, because while I see your point, I also see that there is a dependency problem which he must solve (and no it's not as big as Firefox), and
There is no dependency problems with plugins. Including the plugins would instead create even more dependency problems.
I think, it is reasonable to include the dssi or ladspa header files in imports, or maybe even directly in the dssi~ source directory. It's just that I'm against hosting and including the plugins themselves, for the reasons I explained.
Ciao
On Tue, 2006-03-14 at 10:20 +0000, David Plans Casal wrote:
I don't necessarily agree with that. Perhaps 'imports' isn't the right word, but the fact that a library isn't required to run Pd at all might not be a good enough reason not to include it in an extended build system, especially if it is kept completely apart from the main tree.
still, why not just write a small script to pull the external sources from upstream? (ftp, cvs, svn or whatever)
t
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
I must say I find television very educational. The minute somebody turns it on, I go to the library and read a good book. Groucho Marx
On 14 Mar 2006, at 11:00, Tim Blechmann wrote:
On Tue, 2006-03-14 at 10:20 +0000, David Plans Casal wrote:
I don't necessarily agree with that. Perhaps 'imports' isn't the right word, but the fact that a library isn't required to run Pd at all might not be a good enough reason not to include it in an extended build system, especially if it is kept completely apart from the main tree.
still, why not just write a small script to pull the external sources from upstream? (ftp, cvs, svn or whatever)
I would rather see that too, of course. Has hc not explained why he - isn't- doing that already?
d
-- David Casal Researcher, Department of Computing Goldsmiths College, University of London Office : +44 020 7078 5151 Mob : +44 07803 173959
David Plans Casal wrote:
still, why not just write a small script to pull the external sources from upstream? (ftp, cvs, svn or whatever)
I would rather see that too, of course. Has hc not explained why he - isn't- doing that already?
iirc, the main argument against this is, that debian does not allow to fetch additional "helper" sources from the net.
hc's other point is, that making these sources available in the CVS, is necessary because people not using debian have a hard time getting these sources.
my conclusion is: on systems that have a reasonable package-manager (like debian) use that one; on systems that don't, use the checkout-scripts. so, i don't see a realy conflict here (meaning: i don't see a reason to _not_ use checkout scripts)
afaik, debian's policy generally doesn't really like to use sources directly from CVS (i might be wrong here, though). therefore, for using pd-extended for debian builds, a "source-ball" should be done anyhow (e.g. via a monthly script). this source-ball could then include all the (hard) dependencies that cannot be expected to come with your distro/OS.
i totally agree with frank, that the pd-cvs should not become a place to host dssi-plugins. i also feel towards tim, that projects available otherwise (esp. if they are hosted on sourceforge - which pretty much guarantees their availability, even if the connection is often beyond discussion) should not be incorporated.
however, i think there might be one simple solution: urge the sourceforge staff, that they make /cvsroot/ available as CVSROOT; this way, you could do a: "cvs -d:pserver:anonymous@cvs.sf.net/cvsroot co ." and fetch the world (or use some modified command, to only get the relevant parts)
mfg.a.dsr. IOhannes
On Tue, 14 Mar 2006, IOhannes m zmoelnig wrote:
iirc, the main argument against this is, that debian does not allow to fetch additional "helper" sources from the net. hc's other point is, that making these sources available in the CVS, is necessary because people not using debian have a hard time getting these sources.
don't confuse what would be available by getting the CVS, with what would be available from a debian source package. The latter may include source from more than one CVS.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Tue, 14 Mar 2006, IOhannes m zmoelnig wrote:
iirc, the main argument against this is, that debian does not allow to fetch additional "helper" sources from the net. hc's other point is, that making these sources available in the CVS, is necessary because people not using debian have a hard time getting these sources.
don't confuse what would be available by getting the CVS, with what would be available from a debian source package. The latter may include source from more than one CVS.
that is exactly what i try to say. on debian systems: the restriction imposed by not being allowed to access the net can be circumvent via a debian source package. on non-debian systems: this restriction does not apply.
mfg.asdr. IOhannes
On Mar 14, 2006, at 6:04 AM, David Plans Casal wrote:
On 14 Mar 2006, at 11:00, Tim Blechmann wrote:
On Tue, 2006-03-14 at 10:20 +0000, David Plans Casal wrote:
I don't necessarily agree with that. Perhaps 'imports' isn't the right word, but the fact that a library isn't required to run Pd at all might not be a good enough reason not to include it in an extended build system, especially if it is kept completely apart from the main tree.
still, why not just write a small script to pull the external sources from upstream? (ftp, cvs, svn or whatever)
I would rather see that too, of course. Has hc not explained why he -isn't- doing that already?
Its been discussed quite a bit. There are many reasons:
- Debian auto-builders don't allow network access
- CVS is a far better system for managing code than any script we'll write
- "cvs import" is designed for exactly this purpose
- when using dev libraries, like portaudio, etc, its good that we know which version to compile against, since sometimes Pd will only work with a very specific version, which often isn't marked by anything but a CVS commit date.
and more...
.hc
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
Debian auto-builders don't allow network access
CVS is a far better system for managing code than any script we'll
write
- "cvs import" is designed for exactly this purpose
CVS requires network access. so youre saying at some point in time a snapshot is made, and then uploadedd into debians 'non-networked tarball motherbrain' or something? why couldnt portaudio just be included at that step?
On Mar 18, 2006, at 7:38 PM, cdr wrote:
Debian auto-builders don't allow network access
CVS is a far better system for managing code than any script we'll
write
- "cvs import" is designed for exactly this purpose
CVS requires network access. so youre saying at some point in time a snapshot is made, and then uploadedd into debians 'non-networked tarball motherbrain' or something? why couldnt portaudio just be included at that step?
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.
.hc
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
On Mar 18, 2006, at 7:38 PM, cdr wrote:
Debian auto-builders don't allow network access
CVS is a far better system for managing code than any script we'll
write
- "cvs import" is designed for exactly this purpose
CVS requires network access. so youre saying at some point in time a snapshot is made, and then uploadedd into debians 'non-networked tarball motherbrain' or something? why couldnt portaudio just be included at that step?
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.
.hc
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
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.
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
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
Hans-Christoph Steiner wrote:
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,
please accept, that this is not an option for me!
i do think that pd-extended is great work, but i don't consider myself as the target user. i am happy with using (miller's) pd and some externals which i find useful. i am not at all interested in needing to download a 80MB image instead of just some MB of sources. additionally some sources get customized (patched).
and the application is supposed to run on both 32bit and 64bit platforms. there is no 64bit pd-extended.
and think of it as a programming platform, like Java. The strength is in the collection of all the code.
last time i did a java project, i had to download external libraries, because they were not included in jav (1.4 that was)
again pd-extended is great. but not everything is pd-extended. and should not be!
mfa.d.t IOhannes
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
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,
please accept, that this is not an option for me!
i do think that pd-extended is great work, but i don't consider myself as the target user. i am happy with using (miller's) pd and some externals which i find useful. i am not at all interested in needing to download a 80MB image instead of just some MB of sources. additionally some sources get customized (patched).
Why would you not want to use Pd-extended? It would benefit everyone if the IEM apps where part of Pd-extended, you guys do some great work which should be more widely distributed. Plus, it would make it less work for you to release your apps. It would not be hard to make a stripped down version of Pd-extended to distribute Pd apps. In fact, I think this could be an approach to making "compiled" Pd apps.
It could work like this: download Pd-extended, open your app written in Pd, then select the menu option which checks the deps of that app, and then strips out everything else, and renames the Pd-extended app to the App name. That is quite doable.
and the application is supposed to run on both 32bit and 64bit platforms. there is no 64bit pd-extended.
Let's make a 64-bit Pd-extended then! Again, lots of people will benefit when we join forces.
and think of it as a programming platform, like Java. The strength is in the collection of all the code.
last time i did a java project, i had to download external libraries, because they were not included in jav (1.4 that was)
again pd-extended is great. but not everything is pd-extended. and should not be!
Anything that is a useful library should be included in Pd-extended, just like Java. Its definitely grown a lot over the years. Applications are another story. Its good to have some as examples, but not every Pd application under the sun should be added.
The above Pd-compiling idea could work for that...
.hc
and think of it as a programming platform, like Java. The strength is in the collection of all the code.
installing plugins in eclipse is a few clicks. . installing extensions in firefox is a few clicks. i envision a patch popping up a dialog 'this patch requires GEM, send13, and oggcast~' and cross referencing your platform (Mac OS 10.4 PPC, PD 38.4) and offering an 'OK' button to download & install the binaries (generated via nightly builds of the CVS output to individually accessible files instead of a 80MB .dmg). if the binaries didnt exist or caught some kind of symbol exception on loading, it would compile them, a la CPAN/rubygems, etc - this apparatus would be built in PD, as opposed to C or Tk, and use the standard library (maybe libcurl-bindings, or an HTTP abstraction arund netsocket) to fetch the files, spawn GCC, etc....
i'll get around to writing it once i figure out some more pressing issues, like paying my rent..
last time i did a java project, i had to download external libraries, because they were not included in jav (1.4 that was)
again pd-extended is great. but not everything is pd-extended. and should not be!
mfa.d.t IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
this is what i use for one of my current projects: https://svn.sourceforge.net/svnroot/iem/spatialization/CUBEmixer/trunk/src/l...
I'm just browsing this repository a bit: It is very responsive. Is this indeed the new Sourceforge SVN? Amazing.
Ciao
Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
this is what i use for one of my current projects: https://svn.sourceforge.net/svnroot/iem/spatialization/CUBEmixer/trunk/src/l...
I'm just browsing this repository a bit: It is very responsive. Is this indeed the new Sourceforge SVN? Amazing.
yes it IS sourceforge svn. i think it is so repsonsive, because nobody else is using SVN yet. once projects start using, it might become as slow as cvs.
the real cool thing is, that there is no developer-svn vs. anonymous-svn anymore, so everyone can get the latest and greatest checkout without a time delay.
the bad thing is, that there is (yet, sf is working on it) no ACL mechanism. so i don't think that it is a doable option right now for puredata. (otoh, how many people have tried to commit things to subtrees where they shouldn't ?)
migration from CVS is really a bit painful (it was the first time i did it, so it was probably me) and the iem-cvs had almost no branches/tags (as opposed to the puredata-cvs)
mfg.asdr. IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
migration from CVS is really a bit painful (it was the first time i did it, so it was probably me) and the iem-cvs had almost no branches/tags (as opposed to the puredata-cvs)
I don't know for sure, but I think branches and tags in the CVS are mostly concentrated in the Pd sources. I didn't see many tags in externals or abstractions, where people seem to be a bit lazy with tagging and where branching seldom was necessary.
Ciao
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
On Tue, 2006-03-14 at 10:20 +0000, David Plans Casal wrote:
I don't necessarily agree with that. Perhaps 'imports' isn't the right word, but the fact that a library isn't required to run Pd at all might not be a good enough reason not to include it in an extended build system, especially if it is kept completely apart from the main tree.
still, why not just write a small script to pull the external sources from upstream? (ftp, cvs, svn or whatever)
Well, Hans has already countered this with a reasonable argument: Why not use the existing CVS-infrastructure to do just that? I agree with you in that I don't like it, but I wouldn't be totally against it, as long as we don't try to mirror the world and make pd-extended become something like Knoppix.
Ciao
On Mar 13, 2006, at 6:15 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
A good example would be the DSSI stuff. The fluidsynth plugin code would be in "imports" and the Windows and Mac OS X parts of the Makefile would include the source code in imports. The GNU/Linux part would look in the standard system locations for that stuff.
Well, I guess I misunderstood what should go in imports, and maybe I do have objections: I thought, "imports" was to be intended for libraries, that are required by Pd externals and maybe Pd itself, but not for standalone applications independent from Pd, as the DSSI plugins are? The DSSI folks have their own Sourceforge project, they have their own release system, and their applications are not required to run Pd at all.
I'm still against packaging DSSI, LADSPA or VST plugins with Pd. If the DSSI folks or Steinberg need help to provide binary plugins, then that doesn't concern Pd and thus doesn't belong in the Pd CVS, IMO. Everyone may feel free to give them a hand at ladspa.org or dssi.sf.net but this has got nothing to do with Pd.
I give up on the plugin issue.
Without including them as binaries, only a handful of people who are willing to spend a day figuring out how to compile them will ever use them. For the thousands of Pd users who just want to make art, they will not use the DSSI plugins.
I guess in a couple years, there will be some DSSI packages for people to use...
.hc
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
-
cdr -
David Plans Casal -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Thomas Grill -
Tim Blechmann