<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    That's perfect, I think I know everything I need now.<br>
    I still have to sort out some outdated abstractions and write a
    couple of help patches, and I'm ready to go.<br>
    <br>
    Thanks a lot,<br>
    Joseph<br>
    <br>
    <div class="moz-cite-prefix">Le 18/06/18 à 17:02, IOhannes m
      zmoelnig a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:c3015f1c-ca11-9e95-2818-cc326042095f@iem.at">
      <pre wrap="">On 2018-06-18 16:32, Joseph Larralde wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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)
</pre>
      </blockquote>
      <pre wrap="">
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)


</pre>
      <blockquote type="cite">
        <pre wrap="">I think I got it.
To sum up, if I understand well, I should not worry too much about my
directory structure for development.
</pre>
      </blockquote>
      <pre wrap="">
yes.

</pre>
      <blockquote type="cite">
        <pre wrap="">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,
</pre>
      </blockquote>
      <pre wrap="">
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")

</pre>
      <blockquote type="cite">
        <pre wrap="">(or tweak the makefile to do it for me), and run deken package on it.
</pre>
      </blockquote>
      <pre wrap="">
yes

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
yes

</pre>
      <blockquote type="cite">
        <pre wrap="">
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 ?
</pre>
      </blockquote>
      <pre wrap="">
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

</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>