[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] supercollider tree
On Thursday, June 20, 2002, at 09:50 , Ian Pojman wrote:
On Thursday, June 20, 2002, at 02:29 PM, Ronald J. Kuivila wrote:
supercollider (SuperCollider 3)
[pb project file, etc.]
-etc - BBall.icns
[cocoa source (source)]
- server (SC_server lang)
-lang (language related - BufSource, OSX etc would be put in
here if nowhere else?)
- core (LangSource)
- primitives (LangPrimSource)
- OSC (OSC Source)
- synth (SynthSource)
Have you looked at the CW project for the server end?
(I am waited to get a less ancient copy of CW to do so.)
I would guess that there are significant differences between the app
and the server level, since they play different roles. (For example, I
not see a plug-in construct in the app level code.) Some of the
directory sprawl may have to do with that.
Nope, I'm working on getting a copy now though... I realized that after
I layed out the above, so that's definitely going to affect things.
Also, one argument for keeping the server end as a CodeWarrior
that it will facilitate porting the server to other OS environments
compared to the amount of work that would have to be done... it's not a
very strong argument relatively. especially cause the pbproj is using
the same compiler you will on linux.
actually - you can use a Makefile transparently in Project Builder as
So, I wonder if it is prudent to try to redo the directory structure
without general discussion (and understanding) of why it is the way it
definitely. my and T Slothrop's ideas are a good start but there needs
to be clear separation on the server/client sources.
(since I dont have codewarrior at the moment nothing much I can suggest
on the matter at this point)
What I did to the file hierarchy/pbproj was just to clean it up so it
would be easier to look at and think about. I tried to follow what I
thought were the intentions of the original hierarchy without making any
drastic changes. I also cleared away stuff that won't ultimately be in a
CVS tree. It was a mess in there and now it isn't really...I'm not
trying to hijack this (important) design decision, but I think it would
be beneficial to most people involved in this discussion to take a look
at what I did.
BTW, if the client and server share code it might get messy dividing
things down that line, even though I think it's the right thing to do...
Would it be too much trouble to make two linked CVS repositories?