PureUnity now includes an "external" which is actually 5 lines of C code. I tried hard not using any externals but now I have a real good reason to.
Now, the problem is that PureUnity is in /abstractions/ ... does the build system extend to that directory? Do I have to move PureUnity elsewhere?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
PureUnity now includes an "external" which is actually 5 lines of C code. I tried hard not using any externals but now I have a real good reason to.
Now, the problem is that PureUnity is in /abstractions/ ... does the build system extend to that directory? Do I have to move PureUnity elsewhere?
Hard one. The "build" system also extends over to "abstractions", see abstractions/Makefile. However preferably "abstractions" should be used only for pure abstractions, that is, stuff that can be installed by copying files around without any compilation. Of course abstractions do require certain externals. How about moving just the PU external over to "externals"?
Ciao
On Mon, 2 Jan 2006, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
PureUnity now includes an "external" which is actually 5 lines of C code. I tried hard not using any externals but now I have a real good reason to. Now, the problem is that PureUnity is in /abstractions/ ... does the build system extend to that directory? Do I have to move PureUnity elsewhere?
Hard one. The "build" system also extends over to "abstractions", see abstractions/Makefile. However preferably "abstractions" should be used only for pure abstractions, that is, stuff that can be installed by copying files around without any compilation. Of course abstractions do require certain externals. How about moving just the PU external over to "externals"?
If the buildsystem extends to /abstractions/ then what is the point of keeping /externals/ and /abstractions/ separated? (apart from inertia...)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 5, 2006, at 10:36 PM, Mathieu Bouchard wrote:
On Mon, 2 Jan 2006, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
PureUnity now includes an "external" which is actually 5 lines of C code. I tried hard not using any externals but now I have a real good reason to. Now, the problem is that PureUnity is in /abstractions/ ... does the build system extend to that directory? Do I have to move PureUnity elsewhere?
Hard one. The "build" system also extends over to "abstractions", see abstractions/Makefile. However preferably "abstractions" should be used only for pure abstractions, that is, stuff that can be installed by copying files around without any compilation. Of course abstractions do require certain externals. How about moving just the PU external over to "externals"?
If the buildsystem extends to /abstractions/ then what is the point of keeping /externals/ and /abstractions/ separated? (apart from inertia...)
Currently, things are roughly organized around build system. For Pd objects, there is no compilation, so there isn't really a build system. Right now, /abstractions/ is just Pd objects, so if you want to introduce a C object, don't put it in /abstractions/.
I am open to suggestions how to best organize this, but I think for compiled objects, organizing around compilation system makes the most sense. But Pd objects could really go anywhere.
.hc
________________________________________________________________________ ____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously.
- Benjamin Franklin
On Fri, 6 Jan 2006, Hans-Christoph Steiner wrote:
On Jan 5, 2006, at 10:36 PM, Mathieu Bouchard wrote:
If the buildsystem extends to /abstractions/ then what is the point of keeping /externals/ and /abstractions/ separated? (apart from inertia...)
I am open to suggestions how to best organize this, but I think for compiled objects, organizing around compilation system makes the most sense.
I suppose that you do it because it makes sense, else it wouldn't make sense. However, I'd like to know _why_ it makes sense, which is the question I was trying to imply when asking the aforementioned question at 10:36 PM.
But Pd objects could really go anywhere.
BTW there's /xgui/ /Framestein/ /supercollider/ ... why are those dirs where they are?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 6, 2006, at 10:45 PM, Mathieu Bouchard wrote:
On Fri, 6 Jan 2006, Hans-Christoph Steiner wrote:
On Jan 5, 2006, at 10:36 PM, Mathieu Bouchard wrote:
If the buildsystem extends to /abstractions/ then what is the point of keeping /externals/ and /abstractions/ separated? (apart from inertia...)
I am open to suggestions how to best organize this, but I think for compiled objects, organizing around compilation system makes the most sense.
I suppose that you do it because it makes sense, else it wouldn't make sense. However, I'd like to know _why_ it makes sense, which is the question I was trying to imply when asking the aforementioned question at 10:36 PM.
Because when you mix up files of different types, it makes the pattern matching rules more complicated. I am sure there are other reasons as well, that's the first that comes to mind. It seems to be a standard practice, and its always a good idea to follow standard practice unless you have a good reason not to do so.
But Pd objects could really go anywhere.
BTW there's /xgui/ /Framestein/ /supercollider/ ... why are those dirs where they are?
Because someone stuck them there a long time ago. No better reason than that. /extensions/ would be a good place for xgui, Framestein is defunct, so it doesn't matter. don't know anything about /supercollider/.
.hc ________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it." - Thomas Jefferson
On Sat, 7 Jan 2006, Hans-Christoph Steiner wrote:
Because when you mix up files of different types, it makes the pattern matching rules more complicated. I am sure there are other reasons as well, that's the first that comes to mind.
Does it? wow. Then how come there are so many *.pd files in the /externals/ module ?
Also, I'm curious about how you would break down pureunity into individual externals. Several "classnames" defined in it are aliases (class_addcreator) but not aliases of classes defined in PureUnity! they're aliases for internal classes, e.g.:
[f.inlet] is same as [inlet] [~.inlet] is same as [inlet~]
Would each call to class_addcreator have to go in a separate C file?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 7, 2006, at 12:54 PM, Mathieu Bouchard wrote:
On Sat, 7 Jan 2006, Hans-Christoph Steiner wrote:
Because when you mix up files of different types, it makes the pattern matching rules more complicated. I am sure there are other reasons as well, that's the first that comes to mind.
Does it? wow. Then how come there are so many *.pd files in the /externals/ module ?
I mean more having all of the files in one directory, not which tree its in. But if a lib needs something compiled, it should go into /externals/. That way we don't need to add any compilation stuff to /abstractions/Makefile, which would just be a duplicate of /externals/Makefile
Perhaps a better distinction than /abstractions/ and /externals/ would be /applications/ and /objects/. /applications/ would always be only .pd files since this is the repository for Pd. /objects/ could be any kind of code, since Pd objects can be written in many languages.
Also, I'm curious about how you would break down pureunity into individual externals.
I'd probably have something like:
pureunity/src (*.c) pureunity/abs (*.pd) pureunity/help (*-help.pd)
Several "classnames" defined in it are aliases (class_addcreator) but not aliases of classes defined in PureUnity! they're aliases for internal classes, e.g.:
[f.inlet] is same as [inlet] [~.inlet] is same as [inlet~]
Would each call to class_addcreator have to go in a separate C file?
You could use symlinks, except on Win32, where you would need copies (Win32 doesn't have real symlinks, except with Cygwin.).
.hc ________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
On Sat, 7 Jan 2006, Hans-Christoph Steiner wrote:
On Jan 7, 2006, at 12:54 PM, Mathieu Bouchard wrote:
On Sat, 7 Jan 2006, Hans-Christoph Steiner wrote:
Because when you mix up files of different types, it makes the pattern matching rules more complicated. I am sure there are other reasons as well, that's the first that comes to mind.
Does it? wow. Then how come there are so many *.pd files in the /externals/ module ?
I mean more having all of the files in one directory, not which tree its in.
what's complicated about your pattern-matching needs? I don't understand. why do files have suffixes then?
Perhaps a better distinction than /abstractions/ and /externals/ would be /applications/ and /objects/. /applications/ would always be only .pd files since this is the repository for Pd. /objects/ could be any kind of code, since Pd objects can be written in many languages.
I would object to /objects/ because I think it should be called /classes/ in order to try undoing the object/class confusion that exists in the Max/Pd world.
I'd probably have something like: pureunity/src (*.c) pureunity/abs (*.pd) pureunity/help (*-help.pd)
Why would helpfiles be in the same directory as the corresponding abstractions? And then why do help files have a "-help" suffix then?
Would each call to class_addcreator have to go in a separate C file?
You could use symlinks, except on Win32, where you would need copies (Win32 doesn't have real symlinks, except with Cygwin.).
Wouldn't copies cause "duplicate symbol" errors upon loading?
How would the name of the _setup function be determined in this case?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
what's complicated about your pattern-matching needs? I don't understand. why do files have suffixes then? Why would helpfiles be in the same directory as the corresponding abstractions? And then why do help files have a "-help" suffix then?
Why does Gridflow have all these directories?
base bin bridge bundled cpu devices4ruby doc extra format images java optional pd_abstractions pd_examples pd_help
Why don't you put all this stuff in one big "gf" directory? Why does the "java" directory include only images?
Ciao
On Sun, 8 Jan 2006, Frank Barknecht wrote:
Why does Gridflow have all these directories? base bin bridge bundled cpu devices4ruby doc extra format images java optional pd_abstractions pd_examples pd_help
This question may seem like a parallel to my questions, but there's a big difference: I'm talking about ideal conventions for a fresh new project, whereas your question asks about an existing project with 5 years of baggage which originally wasn't made for Pd, and in which still most of the stuff doesn't depend on Pd, and where directories have been created in a more naïve way back when I didn't know better _and_ back when helpfiles didn't have a "-help" suffix.
Why don't you put all this stuff in one big "gf" directory?
In general, stuff in GF is not organised by filetype. When it is, it's often an old convention that may disappear eventually.
"base" is for essential stuff. "bin" is meant to be installed in $PREFIX/bin. "bridge" contains GridFlow-for-Ruby. "bundled" are files copied from other packages (e.g. g_canvas.h so that people don't have to have Pd's source code in order to compile GF). "cpu" files deal only with CPU-specific optimisations. "devices4ruby" deals only with hardware and used to be a separately distributed package. "doc" is for the XML/HTML-based manual. "extra" is for files that I didn't know where to put. "optional" is for parts whose compilation is not required in order to build GF (USB, LTI), except for those that are file format plugins for [#in] and [#out], which are in "format". "pd_examples" will be renamed to "examples" (possibly merged with "extra"). "pd_help" will disappear as it's being merged with "doc". I'm not sure what to do with "pd_abstractions" yet.
Why does the "java" directory include only images?
The java directory used to contain the client-side jMax code for the [peephole] object. When I nuked jMax support I kept those icons for future use, but I didn't move them (CVS inertia).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sun, 8 Jan 2006, Frank Barknecht wrote:
Why does Gridflow have all these directories? base bin bridge bundled cpu devices4ruby doc extra format images java optional pd_abstractions pd_examples pd_help
This question may seem like a parallel to my questions, but there's a big difference: I'm talking about ideal conventions for a fresh new project, whereas your question asks about an existing project with 5 years of baggage ...
It's not that different at all: The Pd repository is old, too, and it unlike Gridflow it even was organized not by one, but by manymany developers. With some strange results, but at least it has found one rule: Externals that have to be compiled are kept below "externals".
Now you suddenly want to put a tiny single external into "abstractions", where so far only Pd patches are kept.
Instead of providing a really convincing reason why the rule should be broken and why just this external shouldn't be put where all the other externals are you keep asking Hans why CVS is organized the way it is, knowing that the answer is: Because it evolved that way.
Around this evolution, a lot of other evolutions took place: The build system(s) for externals, documentation, packages for distributions, etc. People run their own installations of Pd and they rightfully expect, that what is below "abstractions" can be installed by adding it to the pd-path and be done with it.
Of course there are lots of different and better ways thinkable how to organize the CVS. But any reorganization becomes even harder, if even the most simple conventions are broken without need.
I'd suggest, just do as [hid] does and put PureUnity below "externals". It will make life easier later IMO. There already are a lot of abstractions in "externals" but no externals in "abstractions".
Ciao
-
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard