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.