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

IOhannes m zmölnig zmoelnig at iem.at
Sun Jun 17 19:20:17 CEST 2018


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.

-------------- 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/20180617/cee7135f/attachment.sig>


More information about the Pd-dev mailing list