Hi list,
Apologies if I didn't browse the archives enough before coming here, but I remain with a stupid question.
I have a couple of externals I'd like to publish using deken, and the doc is explicit enough to allow me to do this. But, along with these externals, I have some abstractions I've been using for a while and I'd like to "bundle" them with my library.
What is the cleanest way to organize my stuff in this case ? For example, I looked at cyclone's repo, where I found a nice way to organize my code, its dependencies and the built objects, as well as a collection of abstractions, but there is neither a .dek file nor an objectlist in there, and I'm not sure about how one would proceed to package it with deken.
I guess there must be scripts to achieve this in other existing libraries ... Could anyone please point me to a good example or give me a simple answer ?
Thanks, Joseph
Is this what your a looking for? :
https://github.com/pure-data/deken/blob/master/developer/README.md
--
Mensaje telepatico asistido por maquinas.
On 6/17/2018 8:17 AM, Joseph Larralde wrote:
Hi list,
Apologies if I didn't browse the archives enough before coming here, but I remain with a stupid question.
I have a couple of externals I'd like to publish using deken, and the doc is explicit enough to allow me to do this. But, along with these externals, I have some abstractions I've been using for a while and I'd like to "bundle" them with my library.
What is the cleanest way to organize my stuff in this case ? For example, I looked at cyclone's repo, where I found a nice way to organize my code, its dependencies and the built objects, as well as a collection of abstractions, but there is neither a .dek file nor an objectlist in there, and I'm not sure about how one would proceed to package it with deken.
I guess there must be scripts to achieve this in other existing libraries ... Could anyone please point me to a good example or give me a simple answer ?
Thanks, Joseph
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
No, I've been reading this already and it doesn't mention abstractions. But you're right, I should try deken first and come back with more precise questions. I just wanted to make sure not to push broken things online.
Cheers Joseph
Le 17/06/18 à 13:53, Lucas Cordiviola a écrit :
Is this what your a looking for? :
https://github.com/pure-data/deken/blob/master/developer/README.md
--
Mensaje telepatico asistido por maquinas.
On 6/17/2018 8:17 AM, Joseph Larralde wrote:
Hi list,
Apologies if I didn't browse the archives enough before coming here, but I remain with a stupid question.
I have a couple of externals I'd like to publish using deken, and the doc is explicit enough to allow me to do this. But, along with these externals, I have some abstractions I've been using for a while and I'd like to "bundle" them with my library.
What is the cleanest way to organize my stuff in this case ? For example, I looked at cyclone's repo, where I found a nice way to organize my code, its dependencies and the built objects, as well as a collection of abstractions, but there is neither a .dek file nor an objectlist in there, and I'm not sure about how one would proceed to package it with deken.
I guess there must be scripts to achieve this in other existing libraries ... Could anyone please point me to a good example or give me a simple answer ?
Thanks, Joseph
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Keep in mind that once you've uploaded something it might take 12 (or 24) hours until deken updates the database. So don't be impatient if it doesn't show up on Pd's Deken.
:)
Mensaje telepatico asistido por maquinas.
On 6/17/2018 9:28 AM, Joseph Larralde wrote:
No, I've been reading this already and it doesn't mention abstractions. But you're right, I should try deken first and come back with more precise questions. I just wanted to make sure not to push broken things online.
Cheers Joseph
Le 17/06/18 à 13:53, Lucas Cordiviola a écrit :
Is this what your a looking for? :
https://github.com/pure-data/deken/blob/master/developer/README.md
--
Mensaje telepatico asistido por maquinas.
On 6/17/2018 8:17 AM, Joseph Larralde wrote:
Hi list,
Apologies if I didn't browse the archives enough before coming here, but I remain with a stupid question.
I have a couple of externals I'd like to publish using deken, and the doc is explicit enough to allow me to do this. But, along with these externals, I have some abstractions I've been using for a while and I'd like to "bundle" them with my library.
What is the cleanest way to organize my stuff in this case ? For example, I looked at cyclone's repo, where I found a nice way to organize my code, its dependencies and the built objects, as well as a collection of abstractions, but there is neither a .dek file nor an objectlist in there, and I'm not sure about how one would proceed to package it with deken.
I guess there must be scripts to achieve this in other existing libraries ... Could anyone please point me to a good example or give me a simple answer ?
Thanks, Joseph
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
That's another reason to make sure I don't push broken things too many times :) Right now deken -h is telling me it has a "verifiy" command. Still investigating ...
Le 17/06/18 à 14:34, Lucas Cordiviola a écrit :
Keep in mind that once you've uploaded something it might take 12 (or 24) hours until deken updates the database. So don't be impatient if it doesn't show up on Pd's Deken.
:)
Mensaje telepatico asistido por maquinas.
On 6/17/2018 9:28 AM, Joseph Larralde wrote:
No, I've been reading this already and it doesn't mention abstractions. But you're right, I should try deken first and come back with more precise questions. I just wanted to make sure not to push broken things online.
Cheers Joseph
Le 17/06/18 à 13:53, Lucas Cordiviola a écrit :
Is this what your a looking for? :
https://github.com/pure-data/deken/blob/master/developer/README.md
--
Mensaje telepatico asistido por maquinas.
On 6/17/2018 8:17 AM, Joseph Larralde wrote:
Hi list,
Apologies if I didn't browse the archives enough before coming here, but I remain with a stupid question.
I have a couple of externals I'd like to publish using deken, and the doc is explicit enough to allow me to do this. But, along with these externals, I have some abstractions I've been using for a while and I'd like to "bundle" them with my library.
What is the cleanest way to organize my stuff in this case ? For example, I looked at cyclone's repo, where I found a nice way to organize my code, its dependencies and the built objects, as well as a collection of abstractions, but there is neither a .dek file nor an objectlist in there, and I'm not sure about how one would proceed to package it with deken.
I guess there must be scripts to achieve this in other existing libraries ... Could anyone please point me to a good example or give me a simple answer ?
Thanks, Joseph
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 06/17/2018 02:57 PM, Joseph Larralde wrote:
That's another reason to make sure I don't push broken things too many times :) Right now deken -h is telling me it has a "verifiy" command.
i double checked, and it only has a "verify" command (phew...). however, "verify" will verify the integrity of a downloaded deken package (in terms of sha256 and gpg), rather than verify that the packages has been correctly uploaded; or does anything useful.
gfmadr IOhannes
On 06/17/2018 01:17 PM, Joseph Larralde wrote:
What is the cleanest way to organize my stuff in this case ?
in the source repository, the best way is the one that fits your workflow. it's the only thing that matters.
there are many many libraries that contain both (compiled) externals and abstractions, and they are organizing their source code in different ways.
the users are mostly not concerned about the source structure of your project (they will never see it).
For example, I looked at cyclone's repo, where I found a nice way to organize my code, its dependencies and the built objects, as well as a collection of abstractions, but there is neither a .dek file nor an
thank god. just a general reminder: please do *not ever* include generated files in any source code repository, neither .o files nor .dll or .pd_linux files nor .zip's and .dek's. you are not doing anybody a favour.
objectlist in there, and I'm not sure about how one would proceed to package it with deken.
I guess there must be scripts to achieve this in other existing libraries ...
these scripts are usually called "make install".
but i don't really understand your problem. are you wondering about how to copy files from one directory to another?
probably that's your misunderstanding, so: yes, most externals come with a build script (Makefile) that also includes an option to "install" stuff to be readily usable. in the case of Pd this practically only means to copy various files (compiled (externals) or uncompiled (abstractions, help-patches,...) from the build directory to some destination directory. doing so often flattens the directory structure, so instead of having src/, abstractions/, help/ and examples/ directories, the *installed* directory will have all the required files in .../<libraryname>/ (without much subdirectories).
the point is, that a developer often focuses on different things than a user of a library. so it might make sense to separate the source code (C-files) from Pd-patces in your development directories. but users will want the help-patches besides the externals and abstractions.
Thank you IOhannes for your detailed answer. I will remember not to push any binary files into my repos (something I did in the past because github let me do it)
I think I got it. To sum up, if I understand well, I should not worry too much about my directory structure for development. Whenever I want to make a release I should just copy all my externals (of all available architectures), abstractions and helpfiles in a same folder named appropriately, (or tweak the makefile to do it for me), and run deken package on it. Then I guess all these files will be installed by deken in ~/Documents/Pd/externals or equivalent on the users' machines, and will load properly in pd.
What about the sources ? Is it a good practice put them in a src/ subfolder of the top-level folder containing the externals and patches, before running deken package on it ?
Thanks for your patience, Joseph
Le 17/06/18 à 19:20, IOhannes m zmölnig a écrit :
On 06/17/2018 01:17 PM, Joseph Larralde wrote:
What is the cleanest way to organize my stuff in this case ?
in the source repository, the best way is the one that fits your workflow. it's the only thing that matters.
there are many many libraries that contain both (compiled) externals and abstractions, and they are organizing their source code in different ways.
the users are mostly not concerned about the source structure of your project (they will never see it).
For example, I looked at cyclone's repo, where I found a nice way to organize my code, its dependencies and the built objects, as well as a collection of abstractions, but there is neither a .dek file nor an
thank god. just a general reminder: please do *not ever* include generated files in any source code repository, neither .o files nor .dll or .pd_linux files nor .zip's and .dek's. you are not doing anybody a favour.
objectlist in there, and I'm not sure about how one would proceed to package it with deken.
I guess there must be scripts to achieve this in other existing libraries ...
these scripts are usually called "make install".
but i don't really understand your problem. are you wondering about how to copy files from one directory to another?
probably that's your misunderstanding, so: yes, most externals come with a build script (Makefile) that also includes an option to "install" stuff to be readily usable. in the case of Pd this practically only means to copy various files (compiled (externals) or uncompiled (abstractions, help-patches,...) from the build directory to some destination directory. doing so often flattens the directory structure, so instead of having src/, abstractions/, help/ and examples/ directories, the *installed* directory will have all the required files in .../<libraryname>/ (without much subdirectories).
the point is, that a developer often focuses on different things than a user of a library. so it might make sense to separate the source code (C-files) from Pd-patces in your development directories. but users will want the help-patches besides the externals and abstractions.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 2018-06-18 16:32, Joseph Larralde wrote:
Thank you IOhannes for your detailed answer. I will remember not to push any binary files into my repos (something I did in the past because github let me do it)
good. (note: git of course allows you to track "binary" data; e.g. it's perfectly valid to check jpegs into your repository; there might even be edge cases that would mandate to track compiled stuff; but in general you don't want to track things that your build process generates for you. for one thing, recompiling your code shouldn't mark your project as "dirty", because tracked files changed (because they are not bit-for-bit identical, because some system header files have changed)
I think I got it. To sum up, if I understand well, I should not worry too much about my directory structure for development.
yes.
Whenever I want to make a release I should just copy all my externals (of all available architectures), abstractions and helpfiles in a same folder named appropriately,
yes. depending on the size of your library, you also might want to create multiple deken packages, one per architecture. (just repeat the process outlined by you with subsets of architectures rather than "all available archs")
(or tweak the makefile to do it for me), and run deken package on it.
yes
Then I guess all these files will be installed by deken in ~/Documents/Pd/externals or equivalent on the users' machines, and will load properly in pd.
yes
What about the sources ? Is it a good practice put them in a src/ subfolder of the top-level folder containing the externals and patches, before running deken package on it ?
yea. deken tries to nag you into also publishing your sources (and build system). usually you don't want to clutter the directory the user is likely to browse with source code (most users won't be able to do much with them anyhow), so putting them aside into a src/ folder is fine. it would be nice to also include the build-system (e.g. your Makefile) with the sources, so the project can be rebuild from the deken package.
an alternative to stuffing things into "src/" is to just create a separate source-only package (e.g. just take a snapshot of your development directory, without any compiled stuff and without the git- (or other vcs-) files. something like:
$ rm -rf mylibrary $ git archive --format=tar --prefix=mylibrary/ HEAD | tar xf - $ deken package --version=1.2.3 mylibrary
you can then upload the generated source package ("mylibrary[v1.2.3](Sources).dek") either before or together with the "binary packages" (that contain the actual compiled externals). deken should detect that you've uploaded sources (or are going to) and will not complain.
fgmasdr IOhannes
That's perfect, I think I know everything I need now. I still have to sort out some outdated abstractions and write a couple of help patches, and I'm ready to go.
Thanks a lot, Joseph
Le 18/06/18 à 17:02, IOhannes m zmoelnig a écrit :
On 2018-06-18 16:32, Joseph Larralde wrote:
Thank you IOhannes for your detailed answer. I will remember not to push any binary files into my repos (something I did in the past because github let me do it)
good. (note: git of course allows you to track "binary" data; e.g. it's perfectly valid to check jpegs into your repository; there might even be edge cases that would mandate to track compiled stuff; but in general you don't want to track things that your build process generates for you. for one thing, recompiling your code shouldn't mark your project as "dirty", because tracked files changed (because they are not bit-for-bit identical, because some system header files have changed)
I think I got it. To sum up, if I understand well, I should not worry too much about my directory structure for development.
yes.
Whenever I want to make a release I should just copy all my externals (of all available architectures), abstractions and helpfiles in a same folder named appropriately,
yes. depending on the size of your library, you also might want to create multiple deken packages, one per architecture. (just repeat the process outlined by you with subsets of architectures rather than "all available archs")
(or tweak the makefile to do it for me), and run deken package on it.
yes
Then I guess all these files will be installed by deken in ~/Documents/Pd/externals or equivalent on the users' machines, and will load properly in pd.
yes
What about the sources ? Is it a good practice put them in a src/ subfolder of the top-level folder containing the externals and patches, before running deken package on it ?
yea. deken tries to nag you into also publishing your sources (and build system). usually you don't want to clutter the directory the user is likely to browse with source code (most users won't be able to do much with them anyhow), so putting them aside into a src/ folder is fine. it would be nice to also include the build-system (e.g. your Makefile) with the sources, so the project can be rebuild from the deken package.
an alternative to stuffing things into "src/" is to just create a separate source-only package (e.g. just take a snapshot of your development directory, without any compiled stuff and without the git- (or other vcs-) files. something like:
$ rm -rf mylibrary $ git archive --format=tar --prefix=mylibrary/ HEAD | tar xf - $ deken package --version=1.2.3 mylibrary
you can then upload the generated source package ("mylibrary[v1.2.3](Sources).dek") either before or together with the "binary packages" (that contain the actual compiled externals). deken should detect that you've uploaded sources (or are going to) and will not complain.
fgmasdr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Joseph Larralde -
Lucas Cordiviola