I think this could be a good idea, but it will be quite a bit of work. As long as we share a single build system, I think it will work. The current one is already pretty modular, but it could use more work, like a proper ./configure setup.
I am currently in the process of helping Nando @ CCRMA to base his PlanetCCRMA Pd packages off of the extended build system, and its mostly working quite well. But the process is highlighting some areas that need work.
.hc
On Aug 7, 2006, at 7:02 PM, Alexandre Quessy wrote:
By the way, the PEAR packaging system is very good for handling versions and dependencies of several files. It works on several OS (mac/win/*nix) and there is a GUI to make the packages.
I tought about using that for creating PD packages (externals and abstractions), but then, we thought that PEAR needs PHP, which is not installed by default on Win32 nor on most Linux distros. We could write our own packaing system. It must be about 1000 lines of code. It could be in Python. I think that would help a lot the community to get organized. I"d be volunteer to work (in a team) on it if I was sure the community (and Miller) would accept it.
Also, I know there exist such package managers that could be used for that. Maybe not APT : there are some that are more portable. Marc Lavallée told about about one one day, but I forgot which.
This thread should be switched to the pd-dev list now...
aalex
On 8/7/06, Alexandre Quessy listes@sourcelibre.com wrote:
On 7/31/06, matthew jones mj@isvr.soton.ac.uk wrote:
A double-clickable jar-style format would be good to do so
that you can
include more than one file.
I second that! Distribution of patches which include other
patches,
specific abstractions and externals would be peasy and clean
with some kind
of packaged format like that. Then even if these abstractions
etc were
already installed on the user's machine the patch would look for
anything
required within this packaged file first... no longer any
[scale] confusions
or namespace issues! Oh, but then externals are platform
dependent, so....
hmm patches become dependent too. Right... maybe not the
optimal solution
then?
Very good idea !! It could be a ZIP file with a XML file, patches and objects in it. The XML file describes the role of each file in the bundles. Therefore, one could wrap externals for, let say, Windose, Mack and Linux, and write the ".pdrc" in the xml file. If the externals are missing for the current OS, well, it doesn't work and that's it ! An example of such a XML file in a TAR.GZ package is the package system of PEAR, the PHP classes repository. See http://www.php-editors.com/pear_manual/developers.packagedef.html
Maybe that's overkill though, but it would kind of compete with Max's VSTs. :-P
Cheers,
a
Matt
-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org -=-=-=-=-=-=-=-=-=-=-=-
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/
listinfo/pd-list
-- Alexandre Quessy http://alexandre.quessy.net
-- Alexandre Quessy http://alexandre.quessy.net
------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
On 8/7/06, hans@eds.org hans@eds.org wrote:
I think this could be a good idea, but it will be quite a bit of work. As long as we share a single build system, I think it will work. The current one is already pretty modular, but it could use more work, like a proper ./configure setup.
Yes. You are right : I forgot that it is better to compile everything together. I think I need a crash course on the pd-extended build system... I will study a bit, soon. :-)
I am currently in the process of helping Nando @ CCRMA to base his PlanetCCRMA Pd packages off of the extended build system, and its mostly working quite well. But the process is highlighting some areas that need work.
Yeah. Taking shores is a good way to learn too. Maybe a ticket system, or a much used wiki, would be great. I am thinking about http://trac.edgewall.org/ and such.
.hc
On Aug 7, 2006, at 7:02 PM, Alexandre Quessy wrote:
By the way, the PEAR packaging system is very good for handling versions and dependencies of several files. It works on several OS (mac/win/*nix) and there is a GUI to make the packages.
I tought about using that for creating PD packages (externals and abstractions), but then, we thought that PEAR needs PHP, which is not installed by default on Win32 nor on most Linux distros. We could write our own packaing system. It must be about 1000 lines of code. It could be in Python. I think that would help a lot the community to get organized. I"d be volunteer to work (in a team) on it if I was sure the community (and Miller) would accept it.
Also, I know there exist such package managers that could be used for that. Maybe not APT : there are some that are more portable. Marc Lavallée told about about one one day, but I forgot which.
This thread should be switched to the pd-dev list now...
aalex
On 8/7/06, Alexandre Quessy listes@sourcelibre.com wrote:
On 7/31/06, matthew jones mj@isvr.soton.ac.uk wrote:
A double-clickable jar-style format would be good to do so
that you can
include more than one file.
I second that! Distribution of patches which include other
patches,
specific abstractions and externals would be peasy and clean
with some kind
of packaged format like that. Then even if these abstractions
etc were
already installed on the user's machine the patch would look for
anything
required within this packaged file first... no longer any
[scale] confusions
or namespace issues! Oh, but then externals are platform
dependent, so....
hmm patches become dependent too. Right... maybe not the
optimal solution
then?
Very good idea !! It could be a ZIP file with a XML file, patches and objects in it. The XML file describes the role of each file in the bundles. Therefore, one could wrap externals for, let say, Windose, Mack and Linux, and write the ".pdrc" in the xml file. If the externals are missing for the current OS, well, it doesn't work and that's it ! An example of such a XML file in a TAR.GZ package is the package system of PEAR, the PHP classes repository. See http://www.php-editors.com/pear_manual/developers.packagedef.html
Maybe that's overkill though, but it would kind of compete with Max's VSTs. :-P
Cheers,
a
Matt
-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org -=-=-=-=-=-=-=-=-=-=-=-
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/
listinfo/pd-list
-- Alexandre Quessy http://alexandre.quessy.net
-- Alexandre Quessy http://alexandre.quessy.net
¡El pueblo unido jamás será vencido!
-
Alexandre Quessy -
hans＠eds.org