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