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

[Joseph Larralde]

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 at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20180618/882dd38d/attachment.html>