|
The exchange between myself and another project team member copied below represents an initial foray changing the way we handle the gnuspeech source. It seems appropriate to ask list members for their input before making any changes, so please consider yourselves asked and post replies to the list.
David Hill Project admin --------
Hi David,
On 5-Nov-08, at 4:54 PM, David Hill wrote: Hi Dalmazio, On Nov 5, 2008, at 11:31 AM, Dalmazio Brisinda wrote: [...]
What do you think? Two separate development branches? Yea or nea?
Your arguments make good sense, but I feel it would be a bad move to separate into two branches:
1. There would then be two different sets of code to maintain and -- as far as possible -- synchronise which could get increasingly onerous & therefore not done, or at least not done well;
The problem with keeping them as one is the all-or-nothing approach to development. It might be difficult to find resources that would allow for work on *both* the GNUSTEP and OS X versions to occur in parallel. Tying them together like this may create obstacles to further progress. If they were separated, development has a higher chance of proceeding, on one platform or the other, and changes made on one platform could be rolled into the other platform when someone who was so inclined came along. And there would be two functioning versions of the software at all times. But, yes, it's true, it might not get done right away...
2. This is supposed to be a GNU project, not a Mac project; and
I understand. What if I reworded myself to say that the GNUSTEP version is the reference implementation, and the OS X version is the experimental branch implementation, for which programmer resources are currently available? It should be a relatively straightforward matter for someone who was serious enough to port an existing system from one platform to the other. But more difficult to develop them in parallel.
3. It is a good discipline to have one source for both environments because (for example) resolving the Core Audio issue is probably best done by making a new audio back end that will run in either and avoids the complexity of Core Audio (and one less thing for Apple to mess with and break our system) so a single source is a useful incentive to make such moves.
That's true -- just tossing out CoreAudio in favor of NSSound (the newer 10.5 NSSound has some additional features for playback) might be best for the time being. That's what I did to get Monet synthesis to work on 10.5.5 (bypassed CoreAudio) as I couldn't get CoreAudio to work -- very cryptic + something is changed/broken. But it comes back to that all-or-nothing approach. If you can't have a solution that works on both platforms for the time being, would you settle for a solution that works on one platform only, where changes could be ported later? And it's not like the software would be broken on one platform, it would just lag behind a bit as far as features etc.
The point about all those conditional compilation macros is a good one though. Perhaps worth some auxiliary tool that allows you to view the code based on whichever conditional compilation you are currently expanding/debugging -- not as simple as it sounds, I realise.
Do you agree with me?
Yes, and no. I hear your concerns. I guess it depends on what your priorities are. For example, no interface changes can be made presently without breaking the GNUSTEP interface, as it uses gorm files instead of nib/xib. Also, the existing Monet nib files are broken on the lastest Xcode (won't open in Interface Builder). I've corrected this and am now using the newer (XML-based) .xib format.
Here, this excerpt from Robert Slover helps illustrates my point, but related to project structure:
A related issue was the need to do some refactoring to arrange
GNUspeech so that it builds more like an ordinary set of libraries. My
understanding is that the current arrangement exploits Xcode's ability
to pull together files that are spread throughout a project in order to
build a particular target, something that is much more difficult to
pull off with ordinary makefiles.
Eventually, there will be changes that will need to be made to the project structure as well, making not just having one source difficult, but also having one project structure difficult.
Thoughts?
Best, dalmazio
|