Hi all
You might remember from last year that I wanted to distribute externals along with an abstraction library (Context) so that new users can download and get it working in as few clicks as possible, without having to download a bunch of extra libraries (see the thread: "[PD] repackaging externals on Deken"). This is in response to many users struggling with the installation process, and it would seem important if Context is every going to go up on Deken.
This week, I've finally gotten around to trying to implement this, but I'm getting hopelessly confused, since I don't have a good understanding of how [declare] works and it's function seems to be changing anyway. I've attempted to outline my questions as clearly as possible, and I would appreciate if people could reply to them individually. I'm not trying to be stubborn, it's just that I'm struggling with my understanding here.
CURRENT SITUATION:
- Context relies heavily on externals, namely zexy, cyclone, else, iemguts, hcs, list-abs, iemmatrix, and flatgui.
- I have everywhere called externals using the [library/object] method, ie. [cyclone/iter], avoiding the use of [declare], because I'm afraid of it. The only time I've use declare is with [declare -stdlib zexy]
OBJECTIVES:
- I want all of Context's externals to be distributed and declared internally.
- For efficiency, I want only those externals which are used in the folder, not the whole library (otherwise it takes up around 38mb).
- For clarity, I want them organized by library in a special "ctx_externals" folder. So there will be one "ctx_externals/cyclone" folder containing only the cyclone externals I use, one "externals/else" folder, etc.
QUESTIONS:
- The easiest way to achieve this would just be to declare them in the object names, ie. [ctx_externals/cyclone/iter]. What is wrong with doing it this way?
- 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.
- Again assuming that 1 is wrong, do I need to remove the "library/" from each of the objects in the patch after using [declare]? (Ie. so [cyclone/iter] becomes just [iter]). It seems to work with the path still specified, but I don't know if this is altering the behavior. Removing the paths in the objects would be a hassle, but I'll do it if there is a reason.
- How many different versions of each external library do I need to provide to cover all possible uses? Windows, Linux & Mac = 3 versions. Do I need to also release one for 32bit and one for 64bit, = 6 versions?
- Is it OK just to put all of these different versions in the same folder, so that "ctx_externals/cyclone" contains 3 x each external, one for each OS? Or will this create problems?
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, which leads me to the next question:
6: If I replace [declare -lib ctx_externals/zexy -path ctx_externals/cyclone -path ctx_externals/else ...] in the main Context file with [declare -lib zexy -path cyclone -path else ...], will it then abandon the repackaged externals and look instead for whatever externals the user has installed? If not this, then what use of [declare] will switch back to the standard behavior?
Thanks for bearing with me here,
Liam