Hi folks, I need some advice on what is the expected way for a package to be laid out to avoid confusing users when they try to install. The situation is that s4pd requires the external, and scm files that come in the package. In development, I have those in an scm dir, and if you build from source, that dir needs to be in the Pd search paths. For a non developer user, I want install to be as simple as possible. Should a downloadable package just put the scm files and external in the top level of the package ('s4pd') so that this can simply be put in the Pd/externals directory? I just need to know what "normal" is for a release package.
thanks iain
On 10/4/21 5:22 PM, Iain Duncan wrote:
of the package ('s4pd') so that this can simply be put in the Pd/externals directory? I just need to know what "normal" is for a release package.
yes: ship the scm files besides your external.
the easiest way is to instruct people to load your library with [declare -path s4pd -lib s4pd] (which will add .../s4pd to Pd's search paths and *also* load the s4pd.pd_linux external). in the s4pd_setup() (or better: s4pd_new()) callback, spit out a big fat wraning if the scm files cannot be found like:
ERROR: could not find 's4pd.scm'! ERROR: use [declare -path s4pd -lib s4pd] to load this external
and refuse to create an instance of the interpreter.
to make things a bit nicer, you could *additionally* search for "s4pd/s4pd.scm", and only bail out if neither of the two can be found.
you could also check how other language bindings do this, e.g. [tclpd] or [pdlua] (both of which somehow try to get the path of the library file, and then use that to load their auxiliary scripts)
gfmnasdr IOhannes
[tclpd] https://svn.code.sf.net/p/pure-data/svn/trunk/externals/loaders/tclpd/tclpd.c [pdlua] https://svn.code.sf.net/p/pure-data/svn/trunk/externals/loaders/pdlua/src/pdlua.c
PS: we probably should move these to gitlab :-)
On 04/10/2021 16:51, IOhannes m zmoelnig wrote:
[pdlua] https://svn.code.sf.net/p/pure-data/svn/trunk/externals/loaders/pdlua/src/pdlua.c
PS: we probably should move these to gitlab :-)
I don't know if it is the very latest/greatest, but there is also https://github.com/agraef/pd-lua
Claude
Thanks, IOhannes, that sounds sensible. So in order to make it as homogenous as possible between people who build from source and those who install the package (as ultimately I would like this to be extension friendly at the C level), do you think it would be best to just have the scm files live in the same directory as the C files in the source? Or is there some suggested approach when using pd lib builder to make this simple?
thanks iain
On Mon, Oct 4, 2021 at 8:52 AM IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 10/4/21 5:22 PM, Iain Duncan wrote:
of the package ('s4pd') so that this can simply be put in the
Pd/externals
directory? I just need to know what "normal" is for a release package.
yes: ship the scm files besides your external.
the easiest way is to instruct people to load your library with [declare -path s4pd -lib s4pd] (which will add .../s4pd to Pd's search paths and *also* load the s4pd.pd_linux external). in the s4pd_setup() (or better: s4pd_new()) callback, spit out a big fat wraning if the scm files cannot be found like:
ERROR: could not find 's4pd.scm'! ERROR: use [declare -path s4pd -lib s4pd] to load this external
and refuse to create an instance of the interpreter.
to make things a bit nicer, you could *additionally* search for "s4pd/s4pd.scm", and only bail out if neither of the two can be found.
you could also check how other language bindings do this, e.g. [tclpd] or [pdlua] (both of which somehow try to get the path of the library file, and then use that to load their auxiliary scripts)
gfmnasdr IOhannes
[tclpd] < https://svn.code.sf.net/p/pure-data/svn/trunk/externals/loaders/tclpd/tclpd....
[pdlua] < https://svn.code.sf.net/p/pure-data/svn/trunk/externals/loaders/pdlua/src/pd...
PS: we probably should move these to gitlab :-)
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Em seg., 4 de out. de 2021 às 13:07, Iain Duncan iainduncanlists@gmail.com escreveu:
Thanks, IOhannes, that sounds sensible. So in order to make it as homogenous as possible between people who build from source and those who install the package (as ultimately I would like this to be extension friendly at the C level), do you think it would be best to just have the scm files live in the same directory as the C files in the source? Or is there some suggested approach when using pd lib builder to make this simple?
You can have it wherever in the source, on github. You just need to have a makefile that builds everything nicely for you the way it needs to be.
who build from source
If people build from source, they are also expected to install it, since the installation process is responsible for assembling all the files at the appropriate location.
pd-lib-builder already has sane default installation paths for "make install" (which, of course, can be overriden). The result should look the same as an (extracted) Deken package, so you don't have to treat it differently.
Christof
On 04.10.2021 18:06, Iain Duncan wrote:
Thanks, IOhannes, that sounds sensible. So in order to make it as homogenous as possible between people who build from source and those who install the package (as ultimately I would like this to be extension friendly at the C level), do you think it would be best to just have the scm files live in the same directory as the C files in the source? Or is there some suggested approach when using pd lib builder to make this simple?
thanks iain
On Mon, Oct 4, 2021 at 8:52 AM IOhannes m zmoelnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:
On 10/4/21 5:22 PM, Iain Duncan wrote: > of the package ('s4pd') so that this can simply be put in the Pd/externals > directory? I just need to know what "normal" is for a release package. yes: ship the scm files besides your external. the easiest way is to instruct people to load your library with [declare -path s4pd -lib s4pd] (which will add .../s4pd to Pd's search paths and *also* load the s4pd.pd_linux external). in the s4pd_setup() (or better: s4pd_new()) callback, spit out a big fat wraning if the scm files cannot be found like: > ERROR: could not find 's4pd.scm'! > ERROR: use [declare -path s4pd -lib s4pd] to load this external and refuse to create an instance of the interpreter. to make things a bit nicer, you could *additionally* search for "s4pd/s4pd.scm", and only bail out if neither of the two can be found. you could also check how other language bindings do this, e.g. [tclpd] or [pdlua] (both of which somehow try to get the path of the library file, and then use that to load their auxiliary scripts) gfmnasdr IOhannes [tclpd] <https://svn.code.sf.net/p/pure-data/svn/trunk/externals/loaders/tclpd/tclpd.c <https://svn.code.sf.net/p/pure-data/svn/trunk/externals/loaders/tclpd/tclpd.c>> [pdlua] <https://svn.code.sf.net/p/pure-data/svn/trunk/externals/loaders/pdlua/src/pdlua.c <https://svn.code.sf.net/p/pure-data/svn/trunk/externals/loaders/pdlua/src/pdlua.c>> PS: we probably should move these to gitlab :-) _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at> https://lists.puredata.info/listinfo/pd-dev <https://lists.puredata.info/listinfo/pd-dev>
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Em seg., 4 de out. de 2021 às 12:52, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
to make things a bit nicer, you could *additionally* search for "s4pd/s4pd.scm", and only bail out if neither of the two can be found.
you could also check how other language bindings do this, e.g. [tclpd] or [pdlua] (both of which somehow try to get the path of the library file, and then use that to load their auxiliary scripts)
Yeah, I think this is the best option and it's what I was suggesting Ian to do. The [s4pd] can be easily loaded without declare if it resides in a folder also called "s4pd" in "externals", cause Pd just searches inside folders with the same name as the object.
Hence, if the object also looks for these needed files on the same folder, it's as simple as can be.
Moreover, other files that you open with [s4pd] (specific scripts) can follow the same usual way of searching for them in the same folder as the patch, and in the user added paths (also being able to specify subfolders and whatnot via "folde/" prefixes and stuff)
-
Alexandre Torres Porres -
Christof Ressi -
Claude Heiland-Allen -
Iain Duncan -
IOhannes m zmoelnig