nice tune :) 2018-04-13 16:51 GMT-03:00 Lucas Cordiviola <lucard...@hotmail.com>:
> Hi Liam, > > Take a look at this example: ---> http://lucarda.com.ar/lucarda2010b.rar > > I distribute externals in the "externals" folder and also their licenses > (see: data/externals/Licenses/readme.html). > > I only do [declare -path %%]. I'm using some objects from Zexy but from > the v00-extended (single binary ones). > > In this example I only use [ggee/image] and the rest of the externals are > not used. This externals package is what i require for other "Pd Albums" > available on my site. (This is just my unified pkg ) > > PS: Last month I did an especial w64 folder with self-compiled externals > for windows 64-bit. I was lucky that my unified pkg has few externals (and > sources available) and it was easy to compile them with pd-lib-builder. > > Hope it helps, > Lucarda. > > > -- > > Mensaje telepatico asistido por maquinas. > > On 4/13/2018 2:41 PM, Liam Goodacre wrote: > > Thanks Alex, you've pretty much answered all my questions. I have a bit of > confusion though, because for me, [declare] in 0.48 does seem to add custom > search paths (see attached screenshot). Doesn't this contradict what you > said? > > As to whether I should do it or not, I have users telling me that I should > and developers telling me that I shouldn't, which puts me in a bit of a > bind. Ultimately, I'm worried that a complex install process will scare a > lot of new users off, which is why I'm looking for a solution. I've given > up on many computer programs before simply because I couldn't get them to > work in the first 5 minutes; haven't you? > > The previous thread from 2017 seemed to arrive at the conclusion that > there was a compromise to be found by distributing two versions of Context, > one with and one without externals. I've modified this a little in that I > was planning to release one package with externals included and a simple > way of disabling them. The reason for this is simply so that I can avoid > the complication of handling two packages, but I'm willing to be talked > back into the two-package solution if there are compelling reasons. > > Now that you have clarified the difference between declaring via paths and > via [declare], I have another idea. What if I do the following: > > 1. Go back to using [library/object] everywhere and [declare] nowhere > (save for Zexy); > 2. Include a "cyclone" and "zexy" etc. folder with the relevant > objects in the main Context folder, not in a special "ctx_externals" > folder. > > This way, Context will find the local externals by default, meaning that > the user doesn't have to bother with downloading them. The readme file then > provides simple instructions that if the user doesn't want to use the local > externals, s/he can simply delete the given folders. All of the external > objects in the Context patch, which are given as [library/object], proceed > to search for the relevant object in "PD documents". This seems about as > simple as it ever could be. Or am I wrong? > > Liam > > > *From:* Alexandre Torres Porres <por...@gmail.com> <por...@gmail.com> > *Sent:* 13 April 2018 15:43 > *To:* Liam Goodacre > *Cc:* PD list > *Subject:* Re: [PD] How to declare custom libraries in abstractions > > 2018-04-13 8:21 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>: > > > > 2018-04-13 4:10 GMT-03:00 Liam Goodacre <liamg...@hotmail.com>: > > > distributing externals along with an abstraction is bad form like you > said, in my opinion > > > 1. Assuming that there is something wrong with the method outlined > above, what is the proper use of [declare] in this instance?* [declare > -lib ctx_externals/zexy -path ctx_externals/cyclone -path > ctx_externals/else ...]* seems to work for me here, but I know that > the use of -path and -lib is changing, so I just want to be sure. > > current behaviour of [declare -path] works for objects in paths related to > the patch, so yeah, this works. And this won't change > > > > So, when do you want to use "libname/external" and when should you just > use "external"? I think this is important to mention and is related to this > question. First, how should you use it? You need to have the parent folder > where the external folders are included to be added to the search path. > Since Pd 0.48, Pd creates a "Pd documents" folder for you and also an > "externals" folder in there, and this folder is automatically added to the > search paths (that is if you just agree to Pd's suggestions when opening > the application for the first time). In macOS, for instance, this is > ~/Documents/Pd/externals > > So, for whatever libraries you include in that folder, for example, you > can use the "libname/external" method and it will work. Cause it'll > search inside ~/Documents/Pd/externals for the "libname/" subfolder and > then the external. Now, if you also add the "libname/" path, even though > you already have > ~/Documents/Pd/externals as a search path, what you have now is the option > to not worry about using "libname". > > But I like using "libname/external" because: 1) it makes it explicit > where this object comes from. 2) It avoids possible nameclashes with other > externals that have the same name and might be called eariler in the search > priority. 3) It doesn't need [declare] in the patch. > > Currently [declare] doesn't work if you want to call paths from user added > paths anyway, so you can't use it if you want to call externals from there. > But if https://github.com/pure-data/pure-data/pull/205 is merged, then > this changes, and [declare -path] will be able to include subfolders > relative to user added paths. For me, this is a crucial feature, as it > basically makes [declare] useless for me right now, when I'm including all > my externals in ~/Documents/Pd/externals - so I either have to use > "libname/external" or add the external subfolder as well to the user added > paths. > > > > I expect that some of you will bring up the point that distributing > externals along with an abstraction is bad form, as it might interfere > with the user's own versions of the same externals. The solution we > arrived at in the last thread was to let the user decide whether to have > Context provide its own externals (basic), or whether to provide them > manually (advanced). This is what I intend to achieve,. > > > Yeah, it might interfere with other versions and stuff, but the point here > maybe is how we want to handle dependencies. And all in one, it just looks > like a hideous kludgy and counterproductive strategy, to me. > > I think ideally we should have an external manager that install missing > dependencies, and this has been discussed here. Like, Pd could sense a > patch wants an external from cyclone and, if you don't have it, it asks you > if you want to download or install it. Yeah, but I don't see anything like > that coming right away, maybe something like it, in this direction, some > time later. So what to do for now? > > Well, another deal is that it should be clear for Pd users to handle > dependencies and installing externals, so all you need to say is this > requires libraries "a, b, c", and they should know how to easily do it > and/or you should provide a nice step by step manual on how they need to > proceed. But perhaps a nice and straightforward common practice for > installing externals in Pd is not yet consolidated, hence all the > questions, debate and proposals for improvement. > > cheers > > > _______________________________________________pd-l...@lists.iem.at mailing > list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list