where is Pd's "-stdlib"? (was Re: request sponsor/upload for pd-pdstring)

[Hans-Christoph Steiner]

On Oct 3, 2011, at 3:54 AM, IOhannes m zmoelnig wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> @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
> team:
>
>
> 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.
>>
>> /usr/lib/pd/extra
>>  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?
>>
>> /usr/lib/puredata/extra
>>  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?
>>
>> /usr/lib/pd-extended/extra
>>  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
> /usr/lib/pd/extra/foo).
> hence i do think that the problem is general problem with Pd-vanilla
> (and not specific to Debian; it only shows here)

My guess is that [declare] should be adapted to consider as stdpath  
the same stuff that -nostdpaths does.


>> 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
> additional /usr/lib/pd/extra/)
>
> i generally tend towards an inclusive solution, though i'm not 100%  
> sure
> whether this is the user expectancy with regards to ~/pd-externals/


[import foo] will load libraries from all paths, I think.  Or at least  
it should.  I never understood [declare]'s -stdpath and -stdlib, that  
lead to me writing [import].

.hc


----------------------------------------------------------------------------

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war on  
terrorism.        - retired U.S. Army general, William Odom