[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
    -src	
	- client
		[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 level and the server level, since they play different roles. (For example, I do
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 projectis that it will facilitate porting the server to other OS environments (i.e.,
Linux).

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 well.


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 is.

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)

Ian


RJK

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?

S