Tcl Source Code

tools/tcl.hpj.in and win/tcl.hpj.in have an additional 
<CR> in the rcs files.  Checking these files out with 
a windows CVS.exe, I get them as cr,cr,lf for <EOL>.  
This is wrong.  Please fix.

The TEA spec states all source files should be in LF 
mode.  But this is not correct because hcw, the help 
compiler, chokes when tcl.hpj is not in CR,LF.  I can 
understand why this file might have been stored in 
CR,LF to ensure a unix cvs client would check it out 
in CR,LF and not cause the tool to crash.  But now it 
crashes anyways when the correct CVS client mode is 
used.  If this was intent, please change it's sticky 
mode to be -kb with `cvs admin -kb tcl.hpj.in` on both 
files.

This appears to be a TEA missunderstanding.  Specing 
that all source files must be in LF mode majorly 
*bombs* when the tools used on these source files 
require a different <EOL> mode!  Wake up people.

I got into a disagreement with Eric Melski about this 
issue last year.  How CVS works regarding <EOL> 
translation is not wrong.  Abuse of CVS line 
translation to fit to a TEA spec that was dead on the 
drawing board is well....  you know what I mean.

Logged In: YES 
user_id=7549

I'm an ass.  Let it all be...  Let's not abuse CVS.

If one uses a CVS client and the translation is LF, so be 
it.  tcl.hpj will choke.  The storage in CVS should not be 
hacked.  CVS behaves the way it does.

If one wants to checkout the tcl source and build with 
microsoft's compiler (either cygwin style TEA or nmake with 
makefile.vc), they had better set their CVS client for CRLF 
translation.  End of story, IMO.

File Added - 6711: noboom_hcw.txt

Logged In: YES 
user_id=7549

The attached patch is an idea for guaranteeing line mode 
before using it.

I see 2 approaches.  Either tag tcl.hpj.in as a binary to 
make sure no line translation happens, or accept CVS's 
behavior and fix it during the build.