where is Pd's "-stdlib"? (was Re: request sponsor/upload for pd-pdstring)
IOhannes m zmoelnig
zmoelnig at iem.at
Mon Oct 3 07:54:28 UTC 2011
-----BEGIN PGP SIGNED MESSAGE-----
@pd-dev: in the course of making packages for debian, we discovered
another slight problem with the "-stdpath" and "-stdlib" flags for
declare (and probably this also expands to the "-nostdpath" startup
flag). following is an excerpt of the discussion in the debian packaging
On 2011-10-01 14:11, Roman Haefeli wrote:
> On Fri, 2011-09-30 at 17:02 +0200, IOhannes m zmölnig wrote:
>> i'm not entirely sure though (given the nastiness of [declare])
>> if you think that it is a bug in "puredata-core", please file a bugreport.
> Yeah, that is indeed the case. Before filing a bug report, I'd like to
> clear up the meanings of the different paths.
> Am I right in assuming that this path is supposed to be searched by
> all flavors of Pd (all packages that provide the virtual package pd)?
> This also the path where usually external libraries are installed to
> because from there they can be loaded from any flavor of pd?
> is only searched by puredata / pd from the puredata package?
> This is where libraries are installed that only are suitable for
> the pd provided by the puredata package?
> is only searched by pdextended / pd from the pd-extended package?
> Libs that are only useful with pdextended go there?
> If that is the case, then there is definitely a bug in the puredata-core
> package as it is ignoring /usr/lib/pd/extra.
it might as well be a bug in puredata upstream (that's why i want to
discuss it; probably a more appropriate place for discussion is the
pd-dev mailinglist which i include in the recipients)
imho, the issue boils down to the question "what are stdpaths?" (and i
assume that "stdlibs" are std because they live in "stdpaths").
for the sake of simplicity, i will only talk about the "linux" version
of Pd (and with Pd i mean Pd-vanilla)
before Pd-0.43 (vanilla!), there was only a single "stdpath", which was
the path were the Pd binaries lived in. this usually was
/usr/local/lib/pd/ or /usr/lib/pd/
since 0.43, a few more paths have been added, namely:
/usr/local/lib/pd-externals and ~/pd-externals
on Debian and derivatives, yet another path is added: since Pd is
installed into /usr/lib/puredata/ (in order to allow pd-extended live
side by side with puredata), the path "/usr/lib/pd" is also added as a
"common system-managed search path".
now all these paths are handled separately from the user defined
search-paths; e.g. they do not show up in the path dialog, and they can
be disabled with the "-nostdpaths" flag.
otoh, [declare] has not adapted to these changes.
if you add "-stdpath extra/foo", it will only search in
/usr/local/lib/pd/extra/foo (given that pd is installed in
/usr/local/lib/pd), but it will not search in
/usr/local/lib/pd-externals/extra/foo nor in ~/pd-externals/extra/foo.
(the same applies for the additional Debian-specific search path
hence i do think that the problem is general problem with Pd-vanilla
(and not specific to Debian; it only shows here)
> This also means, that currently all Pd libraries in unstable that
> install to /usr/lib/pd/extra (most of them do) are currently broken, as
> there is no proper way to actually load them in pd (you still can
> specify the absolute path to the library, which renders your patch
> unportable to other OS').
you could also simply start Pd with "-lib foo" and it will just work.
so i wouldn't consider "all broken".
obviously, we lack the possibility to express a library dependency
within the patch, which is a shame (but which is also due to the current
broken implementation of [declare] in general).
anyhow, what i'm mainly asking is, whether "std" prefixed declare
options and the "std" prefixed cmdline flags are supposed to work on the
same "standard". if so, does this mean to be exclusive (e.g. only have
the Pd install path) or inclusive (additionally have
/usr/local/lib/pd-externals/ and ~/pd-externals/ (and on debian the
i generally tend towards an inclusive solution, though i'm not 100% sure
whether this is the user expectancy with regards to ~/pd-externals/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
More information about the pkg-multimedia-maintainers