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

[Joseph Larralde]

That's perfect, I think I know everything I need now.
I still have to sort out some outdated abstractions and write a couple 
of help patches, and I'm ready to go.

Thanks a lot,
Joseph

Le 18/06/18 à 17:02, IOhannes m zmoelnig a écrit :
> 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
>
>
>
> _______________________________________________
> 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/b07218db/attachment-0001.html>