Hi list, Should "libdir" as a path have any meaning to the Pd user or patch author? I see it in the source code. On GNU/Linux it looks like it points to /usr/lib/pd-- essentially the place for the subdirs doc, extra, etc.
I ask because I just added a "libdir" method to [pdinfo] in Pd-l2ork. It's useful, but maybe there's a better name for that method since it conflicts with the name for a self-contained external library that adheres to Hans' standard format.
-Jonathan
Am 07. November 2014 22:46:35 MEZ, schrieb Jonathan Wilkes via Pd-list pd-list@lists.iem.at:
Should "libdir" as a path have any meaning to the Pd user or patch author?
I dont think so. (I also cannot remember to have needer it ever.)
I see it in the source code.
Afaik it's only used to launch pd-gui and pd-watchdog.
On GNU/Linux it looks like it points to /usr/lib/pd-- essentially the place for the subdirs doc, extra, etc.
Note that it is only *one* of many places for extra. Hans and me spent some time to figure out how to make pd-extended and pd-vanilla co-installable on debian and friends, without duplicating each and every external for both flavours.
The solution was to have multiple "extra" dirs: /usr/lib/$PDFLAVOUR/extra /usr/lib/pd/extra
(And thats on top of all the ~/pd-externals and /usr/local/pd-externals)
so obviously i am mainly concerned about the usability of the value for the location of addons...
I ask because I just added a "libdir" method to [pdinfo] in Pd-l2ork. It's useful,
Could you share some use-cases?
but maybe there's a better name for that method since it conflicts with the name for anl self-contained external library that adheres to Hans' standard format.
How about "pdinstalldir"? (prefixed 'pd' to avoid confusion with the "install" path of the patch.) the "lib" is really just an implementation detail of the FSH.
mfg.ugd.fhj IOhannes
-- Sent from my pdp-11
On 11/08/2014 01:05 AM, IOhannes zmölnig wrote:
Am 07. November 2014 22:46:35 MEZ, schrieb Jonathan Wilkes via Pd-listpd-list@lists.iem.at:
Should "libdir" as a path have any meaning to the Pd user or patch author?
I dont think so. (I also cannot remember to have needer it ever.)
I see it in the source code.
Afaik it's only used to launch pd-gui and pd-watchdog.
On GNU/Linux it looks like it points to /usr/lib/pd-- essentially the place for the subdirs doc, extra, etc.
Note that it is only *one* of many places for extra. Hans and me spent some time to figure out how to make pd-extended and pd-vanilla co-installable on debian and friends, without duplicating each and every external for both flavours.
The solution was to have multiple "extra" dirs: /usr/lib/$PDFLAVOUR/extra /usr/lib/pd/extra
(And thats on top of all the ~/pd-externals and /usr/local/pd-externals)
so obviously i am mainly concerned about the usability of the value for the location of addons...
I ask because I just added a "libdir" method to [pdinfo] in Pd-l2ork. It's useful,
Could you share some use-cases?
My own starting point was a regression test patch for loading all potentially loadable binaries which come with a particular pd installation package. (Well, I say regression test-- when I ran it for the first time it revealed a few objects which have probably always crashed Pd-extended.)
Essentially;
If it crashes, you have the name of the external that probably caused the crash there on the console.
Since the directory that houses "extra" also houses "doc", I just went ahead and made a method for "libdir", which looked to point to parent directory of those two directories.
but maybe there's a better name for that method since it conflicts with the name for anl self-contained external library that adheres to Hans' standard format.
How about "pdinstalldir"? (prefixed 'pd' to avoid confusion with the "install" path of the patch.)
I don't understand what this means. What would the "install" path of a patch be?
I have the scope of the query in the name of the object: [pdinfo]. Currently I have [dir(---[pdinfo] pointing to the directory of the pd executable, but I guess that could be changed.
Anway, what you are calling "pdinstalldir" would return the single directory I am currently calling "libdir". Is that correct?
-Jonathan
the "lib" is really just an implementation detail of the FSH.
mfg.ugd.fhj IOhannes
-- Sent from my pdp-11
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
On 11/10/2014 12:55 AM, Jonathan Wilkes via Pd-list wrote:
On 11/08/2014 01:05 AM, IOhannes zmölnig wrote:
Could you share some use-cases?
My own starting point was a regression test patch for loading all potentially loadable binaries which come with a particular pd installation package. (Well, I say regression test-- when I ran it for the first time it revealed a few objects which have probably always crashed Pd-extended.)
[...]
Since the directory that houses "extra" also houses "doc", I just went ahead and made a method for "libdir", which looked to point to parent directory of those two directories.
so the main purpose of the "libdir path" is indeed to find the "extra" path - i don't think the "doc" path is super-interesting, as these days libraries don't install to it (any more), so content under "doc/" is well defined.
but if "extra" is what you after, then i thik the valueS of "sys_staticpath" are more intersting, as these enumerate all default search paths ("all extra paths").
but maybe there's a better name for that method since it conflicts with the name for anl self-contained external library that adheres to Hans' standard format.
How about "pdinstalldir"? (prefixed 'pd' to avoid confusion with the "install" path of the patch.)
I don't understand what this means. What would the "install" path of a patch be?
well, just the path of the patch, but viewed from an application pov, where you ship an application written in Pd (as opposed to the Pd-application).
i'm aware that you have already added other ways to query *this* info.
I have the scope of the query in the name of the object: [pdinfo]. Currently I have [dir(---[pdinfo] pointing to the directory of the pd executable, but I guess that could be changed.
so this returns /usr/(local/)?bin
on an ordinary linux installation?
Anway, what you are calling "pdinstalldir" would return the single directory I am currently calling "libdir". Is that correct?
yes. this was just a suggestion for an alternate name of "libdir" which does not require the user to know anything about filesystem hierarchy standards...
fgdsamr IOhannes