search

glastonbridge / SuperCollider-Android

An Android port of SuperCollider
http://wiki.github.com/glastonbridge/SuperCollider-Android
GNU General Public License v3.0
122 stars 22 forks source link

List of reasons we can't just dump the SC codebase in the JNI directory #1

Closed glastonbridge closed 14 years ago

glastonbridge commented 14 years ago

When I first added the SC code to a JNI project, I pulled out a lot of stuff to get it to compile. Dan S has removed some dependencies on libs, and CrystaX provides STL, so what's left to tweak?

Not being able to pull the latest SC source into a project is a disadvantage.

glastonbridge commented 14 years ago

I've pulled a few of the latest SC server source files into the project wholesale, and crystax copes admirably. I suspect we're 90% ready to be able to build supercollider source directly. If anyone wants to build a simple merge script that'd be most handy.

danstowell commented 14 years ago

I've synced many of the files currently in the tree, to match the sc 3.4 release. Doing this, I noted the following reasons for differences:

(1) Unavailability of exceptions (crystax now means we can use exceptions? we can just drop these back to their upstream state?):

Source/common/SC_AllocPool.cpp Source/server/SC_ComPort.cpp Source/common/SC_DirUtils.cpp (plus other crufty differences) Source/server/SC_Graph.cpp Source/server/SC_Lib.cpp Source/server/SC_MiscCmds.cpp Source/server/SC_Node.cpp Source/server/SC_World.cpp Source/server/scsynth_main.cpp Headers/server/SC_List.cpp Headers/common/scsynthsend.h (not actually using exceptions tho)

(2) Unavailability of libsndfile - alex is working on this so hopefully this issue can go away soon:

Headers/server/SC_HiddenWorld.h Headers/plugin_interface_SC_SndBuf.h Source/server/SC_SequencedCommand.cpp

(3) different way of calling stdlib headers (c linkage rather than c++) - is this fixable? or is there an argument for pushing these upstream for greater compatibility? I'm not clear on why we needed to do this.

Headers/plugin_interface/SC_BoundsMacros.h (also lack of algorithm) Headers/plugin_interface/SC_Constants.h Headers/plugin_interface/SC_InlineBinaryOp.h Headers/common/SC_fftlib.h Headers/common/scsynthsend.h

(4) Additions for SC_ANDROID that can be pushed upstream

SC_CoreAudio.cpp SCCoreAudio.h SC Lib_Cintf.cpp scsynth_main.cpp

(I haven't checked issues related to files not yet included in the project)

danstowell commented 14 years ago

Also, stdexcept is included but unused in two files: common/Headers/server/PriorityQueue.h, common/Source/server/Samp.cpp. Removed this in upstream - see sc svn rev 10257.

danstowell commented 14 years ago

OK, I believe this is basically fixed. We've sent code upstream and done some things downstream, meaning that our local files are essentially the same as upstream (even if some of the ugen plugins aren't yet included in the build).