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