Dear all
We plan to use the fantastic Deken infrastructure to distribute the Fluid Corpus Manipulation objects (flucoma.org), but also to respect its folder architecture for any other type of download, i.e. GitHub binaries and such things… I read the very clear document here (https://github.com/pure-data/deken/blob/master/developer/README.md) but it is not clear how we can package extra material, like a folder of audio files used in the help files, and now that we can use html files, some extra references… and even maybe an example folder.
Max and SC have clear folder structure for their packaging, and I presume Pd/Deken has it too, but I’ve been unable to locate it, searching the web and the archives of this list. Any pointer welcome.
Thanks
pa
On 12/11/19 10:16 PM, Pierre Alexandre Tremblay wrote:
Dear all
We plan to use the fantastic Deken infrastructure to distribute the Fluid Corpus Manipulation objects (flucoma.org), but also to respect its folder architecture for any other type of download, i.e. GitHub binaries and such things… I read the very clear document here (https://github.com/pure-data/deken/blob/master/developer/README.md) but it is not clear how we can package extra material, like a folder of audio files used in the help files, and now that we can use html files, some extra references… and even maybe an example folder.
just include whatever you want at your won discretion.
vmxadf IOhannes
Dear IOhannes
Thank you for the response. I’m still puzzled, because, for instance, I cannot package the help files tidily in a help folder, they seem to have to share the same folder as the external. Do these need to be top level folder? I can experiment but since I don’t have access to all platform/os combinations, I wondered if there is something that will work across everything.
What I have now, that does not work for help files:
- FluidCorpusManipulation (top folder) - externals (2nd level folder) - all externs - help - all helps and sub patches - audio - all audio - examples - all code examples - ref - all html code
And we are building now the CMake to do the packaging conform. Do you suggest I do
- FluidCorpusManipulation (top folder) - all externals - all helps and sub patches - audio - all audio - examples - all code examples - ref - all html code
That would make a messier top folder but if that is what is needed, we’ll do it.
P
On 11 Dec 2019, at 18:12, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 12/11/19 10:16 PM, Pierre Alexandre Tremblay wrote:
Dear all
We plan to use the fantastic Deken infrastructure to distribute the Fluid Corpus Manipulation objects (flucoma.org), but also to respect its folder architecture for any other type of download, i.e. GitHub binaries and such things… I read the very clear document here (https://github.com/pure-data/deken/blob/master/developer/README.md) but it is not clear how we can package extra material, like a folder of audio files used in the help files, and now that we can use html files, some extra references… and even maybe an example folder.
just include whatever you want at your won discretion.
vmxadf IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Am 12. Dezember 2019 18:53:35 MEZ schrieb Pierre Alexandre Tremblay tremblap@gmail.com:
Dear IOhannes
I cannot package the help files tidily in a help folder, they seem to have to share the same folder as the external. Do these need to be top level folder?
no (or yes, depending on what you mean with "top-level folder")
anyhow, the curreny behaviour is not a limitation of the pkg-format (.dek), but a decision on the Pd-side that was made decades ago.
put simple: - object-definitions (aka "externals") should be on the first-level of your library folder (eg. if the library is called *foo*, yoy'll have " foo/bar.dll", rather than "foo/externals/bar.dll"), else your users will have to jump through hoops to load your library. - help-patches must° be in the same directory as the object-definition (" foo/bar-help.pd"), else pd will not find them. - supplementary material (soundfiles, tutorials, html-documentation, passwords, ...) can go into subfolders (eg "foo/sounds/bell.aif")
this has worked well for quite some time, with simple one-object libs to libraries of several hundreds of objects.
i wouldn't advise to create a superficial sense of "tidiness" that merely creates inconsistency.
mfg.hft.fsl IOhannes
° there are ways to code around that in C, but they often create more confusion
Thanks for this. We will organise as you suggest.
P
On 12 Dec 2019, at 14:58, IOhannes m zmölnig zmoelnig@iem.at wrote:
Am 12. Dezember 2019 18:53:35 MEZ schrieb Pierre Alexandre Tremblay tremblap@gmail.com:
Dear IOhannes
I cannot package the help files tidily in a help folder, they seem to have to share the same folder as the external. Do these need to be top level folder?
no (or yes, depending on what you mean with "top-level folder")
anyhow, the curreny behaviour is not a limitation of the pkg-format (.dek), but a decision on the Pd-side that was made decades ago.
put simple:
- object-definitions (aka "externals") should be on the first-level of your library folder (eg. if the library is called *foo*, yoy'll have " foo/bar.dll", rather than "foo/externals/bar.dll"), else your users will have to jump through hoops to load your library.
- help-patches must° be in the same directory as the object-definition (" foo/bar-help.pd"), else pd will not find them.
- supplementary material (soundfiles, tutorials, html-documentation, passwords, ...) can go into subfolders (eg "foo/sounds/bell.aif")
this has worked well for quite some time, with simple one-object libs to libraries of several hundreds of objects.
i wouldn't advise to create a superficial sense of "tidiness" that merely creates inconsistency.
mfg.hft.fsl IOhannes
° there are ways to code around that in C, but they often create more confusion
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
IOhannes m zmölnig -
Pierre Alexandre Tremblay