<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thank you IOhannes for your detailed answer.<br>
I will remember not to push any binary files into my repos
(something I did in the past because github let me do it)<br>
<br>
I think I got it.<br>
To sum up, if I understand well, I should not worry too much about
my directory structure for development.<br>
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,<br>
(or tweak the makefile to do it for me), and run deken package on
it.<br>
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.<br>
<br>
What about the sources ?<br>
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 ?<br>
<br>
Thanks for your patience,<br>
Joseph<br>
<br>
<div class="moz-cite-prefix">Le 17/06/18 à 19:20, IOhannes m zmölnig
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:268c8fd2-d0d1-30c9-a8aa-9e71e21fe8ff@iem.at">
<pre wrap="">On 06/17/2018 01:17 PM, Joseph Larralde wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
What is the cleanest way to organize my stuff in this case ?
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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 ...
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<!--'"--><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Pd-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pd-dev@lists.iem.at">Pd-dev@lists.iem.at</a>
<a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-dev">https://lists.puredata.info/listinfo/pd-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>