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
_______________________________________________
gnuspeech-contact mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnuspeech-contact
