[Olympus developers 32]: Re: cmucltk changes

[Antoine Raux]

I agree with going for option (2) for now. I think the long term 
solution to all these dependencies and Linux/Windows version issues is 
to make Olympus platform independent and (therefore) remove the VS 
dependency. Even a Cygwin dependency wouldn't be that bad if all of 
Olympus worked that way. The thing I don't like is to require people to 
have both Visual Studio and Cygwin (or whatever non-VS solution we can 
come up with for Windows). I believe that supporting Linux (again while 
keeping the possibility of running through Windows) will remove 
significant (if nothing else psychological) adoption barriers for a 
significant number of potential users. Of course, this is also a lot of 
work...

Also, Thomas raised the issue of the additional burden put on CMUCLMTK 
developers to support VS. The question is: is Olympus the only user of 
CMUCLMTK requiring VS support? If there are indeed many people out there 
who compile the tk under VS then the issue goes beyond Olympus and the 
decision to support or not VS for cmuclmtk should take that into account.

Again, that said, I'm okay with linking to Windows binaries for now.

antoine

Thomas K Harris wrote:
> OK, so this is option (2), where every exported change by the 
> developers requires a compilation and repository check-in under both 
> windows and linux. I don't like reintroducing cygwin and linux into 
> the developers' requirements; presumption of knowledge 
> notwithstanding. But of course the other options have issues, too. 
> I'll make the necessary changes to Olympus to support this.
>
> BTW, We've put a lot of effort into making Olympus easier to use, but 
> I don't think of any current or near-team Olympus developer as an "end 
> user". I don't think Olympus is polished or robust enough yet, and as 
> an open-source and modular system, it encourages research development 
> in all its components.
>
> -Thomas
>
> Alex Rudnicky wrote:
>> Cmculmtk comes with compiled windows native and linux versions
>> (available from sourceforge). There is no reason for an "end user" to
>> work with the source code for this tool, so I think it's ok to just
>> distribute binaries. (This is already necessary for the pronunciation
>> code.)
>>
>> Cmuculmtk had to change because it contained library calls no longer
>> supported by mainstream linux/gnu systems. It was also not structured
>> all that well (I suspect that the latter is what's killing the VS
>> build.)
>>
>> If someone does want to alter the code, the presumption should be that
>> they know enough to deal with Cygwin and perl (if they don't, they
>> shouldn't be fooling around down at that level).
>>
>> Alex
>>
>>
>> -----Original Message-----
>> From: olympus-developers-bounces at LOGANBERRY.srv.cs.cmu.edu
>> [mailto:olympus-developers-bounces at LOGANBERRY.srv.cs.cmu.edu] On Behalf
>> Of TK Harris
>> Sent: Sunday, May 04, 2008 9:41 AM
>> To: Benjamin Frisch
>> Cc: Olympus Developers
>> Subject: [Olympus developers 29]: Re: cmucltk changes
>>
>> A test framework doesn't help what I see are the real problems with (1) 
>> and (2), which are that developers need to develop in multiple 
>> environments regardless of whether the code changes involve os 
>> dependencies. This is already a problem for the sphinxes. As David says,
>>
>> "Every time I switch to Windows an angel dies". Even if an angel doesn't
>>
>> die, he's wasting his time. More often, I'm guessing that the build just
>>
>> gets broken, as happened recently with Alex's changes.
>>
>> (1) If we want to keep VS build stuff, in order to do any file structure
>>
>> changes (including simply adding a file) developers will need to have 
>> windows, visual studio, and linux (or cygwin).
>> (2) This option is even worse. If we want to use binaries, _any_ change 
>> will require the developer to compile in windows and linux.
>>
>> Perhaps this is a good test case for a forth option: cmake or its ilk.
>>
>> -Thomas
>>
>> Benjamin Frisch wrote:
>>   
>>> I am not in favor of introducing a Cygwin dependency as well; however,
>>> I understood the original message to imply that the rebuilt binaries
>>> do not require Cygwin to run.  If the former is true I am ok with a VS
>>> Windows build being pushed off until 2.3; however, I think 1 is ideal
>>> if Cygwin/Unix support for the cmulmtk can be retained along with VS
>>> build support with relative ease in time for 2.2.  (Perhaps, we need a
>>> test framework for this?)
>>>
>>> Ben
>>>
>>> On Sun, May 4, 2008 at 12:06 AM, Antoine Raux <antoine at cs.cmu.edu>
>>>     
>> wrote:
>>   
>>>   
>>>     
>>>> Until we have a Linux version of Olympus, I'm in favor of not
>>>>       
>> introducing a
>>   
>>>> Cygwin dependency, so I prefer solution 1), although I don't know how
>>>>       
>> hard
>>   
>>>> that would be...
>>>>
>>>>  antoine
>>>>
>>>>  TK Harris wrote:
>>>>
>>>>     
>>>>       
>>>>> Recent changes have broken the Visual Studio build of the cmucltk,
>>>>>         
>> which
>>   
>>>>>       
>>>>>         
>>>> Olympus depends on. The stable 2.1 branch of Olympus is pegged to an
>>>>       
>> older
>>   
>>>> version of the toolkit, so for now only the trunk is affected. I see
>>>>       
>> that
>>   
>>>> Alex has improved the cygwin build so that it's well integrated with
>>>>       
>> the
>>   
>>>> linux builds, and yet builds native Windows executables, also it
>>>>       
>> looks like
>>   
>>>> there are binaries checked in.
>>>>     
>>>>       
>>>>> We can either
>>>>> 1) fix the VS build
>>>>> 2) just use checked-in executables
>>>>> 3) require cygwin for an Olympus build
>>>>>
>>>>> I don't really like any of these options; they each have some
>>>>>         
>> negatives.
>>   
>>>>>       
>>>>>         
>>>> I'm open to suggestions.
>>>>     
>>>>       
>>>>> -Thomas
>>>>>
>>>>>
>>>>>       
>>>>>         
>>>>     
>>>>       
>>>   
>>>     
>>
>>
>>
>>   
>