[PD-dev] distributing a collection of externals and abstractions using deken

[IOhannes m zmoelnig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20180618/e2300263/attachment.sig>