Tcl Source Code

Please take off the binary attribute for that file.

If it is an attempt to always make sure it's in CRLF 
no matter what the CVS client checkout translation, it 
isn't a real solution.

CVS behaves the way it does...  Stop fighting it!

If I checked-out the sources with cygwin's CVS and 
(oOpps) didn't use CRLF for the translation mode, and 
expect to build it with the microsoft compiler, the 
checkout was in error, not how the files are stored.

(tcl/win)$ cvs admin -kkv tcl.hpj.in

If I expect to build Tcl with a certain set of tools, 
I (being the developer) had better be aware of my 
checkout translation with CVS.

Logged In: YES 
user_id=72656

fixed in 8.4a4cvs.

Logged In: YES 
user_id=7549

Jeff, You'll need to finish this off.  The repair gets done to the unix makefile as that's where the makedist target is.

Logged In: YES 
user_id=7549

See http://sourceforge.net/tracker/?func=detail&aid=219409&group_id=10894&atid=110894

for the patch to fix this issue.

Logged In: YES 
user_id=7549

I'll play around with a server-side solution in another SF 
project I have, and come back with some better ideas for 
securing the RCS files from corruption, too.

Logged In: YES 
user_id=72656

Good idea Dave.  Please identify those files and make the 
necessary additions to */[Mm]akefile*

Logged In: YES 
user_id=7549

Yup.  I made a commit for getting those files nice and 
<eol> neutral in CVS, but I think we'll need a new makefile 
target.  Something like:

eolfix :
    $(TCLSH) $(TOOLSDIR)/eolFix.tcl <the files to fix>

Logged In: YES 
user_id=75003

Didn't that happen recently ... ?

Logged In: YES 
user_id=79902

IMO, this is a *very* good idea for a new feature for the
Tcl makefile, as it solves the problem in a way that makes
us no longer dependent on the vagaries of CVS.

Logged In: YES 
user_id=7549

Just adding a note to be utterly complete and documented...

One can never guarentee the translation mode of CVS upon 
checkout.  Mac for CR, Win for CRLF, and unix for LF.  The 
intent was to match text file format to the platform format 
of text files.  The main reason for this feature in CVS was 
to allow easy editing.

Building is a slighty different issue.  Conceptually, I see 
nothing wrong with checking out a DOS batchfile on unix in 
LF mode, editing it, then committing changes.  Batch files 
in LF mode won't run!  But the concern is editing.  Old 
fashioned VI won't cause a calamity.  CVS translation lines 
up perfectly when the CVS translation matches the editor 
mode.  No second guessing required.

But building is a different story.  As before, CVS 
translation could be any of 3 choices.  The problem 
of "what translation are we in?" arises when 
building/running/using and especially when grinding builds 
for all platforms from a single checkout/export on a mapped 
drive as is commonly done in large shops for dialies (or 
nightlies).

Because of the "no guarenteed translation", I would suggest 
a make target for fixing the special files that require a 
specific mode as part of the build process.

Logged In: YES 
user_id=7549

Committed changes to core...

Let's not abuse how CVS works.  Let's embrace it, stop 
fighting it, and use it the way it was intended.

If people will need to do a little prefixing of a few files 
because they did an LF checkout and want to use the MS 
compiler, this might be a good clue to them that they 
should align their CVS translation for the platform they 
are building on.

Or run tools/cvtEOL.tcl on a few files.

Logged In: YES 
user_id=7549

>Surely if there is a file that needs a particular
>translation, it should be marked as binary?

No, it needs to be checked-out with the correct translation 
mode.

Same goes for making a source dist.  It's a common "bug" 
that one needs to fix mkd.bat and rmd.bat from tclXX.tar.gz 
before using makefile.vc because the sources were packed 
from an LF checkout.  command.com barfs trying to run those 
batch files.  The same condition applies here.

One can checkout the sources with LF translation, but the 
tools barf building on windows.  This isn't CVS's fault.  
It was the developer's fault for using the wrong 
translation mode.  Doing a single checkout to build for all 
platforms on an NFS share is a nice idea, but it didn't 
work well at Scriptics.

Logged In: YES 
user_id=79902

Surely if there is a file that needs a particular
translation, it should be marked as binary? Particularly as
tcl.hpj.in contains no keywords to substitute anyway.

File Added - 9584: diff.txt

Logged In: YES 
user_id=7549

same goes for tools/tcl.wse.in, too.

If we're to fully accept the behavior of CVS, we'll need to 
fix tools/genStubs.tcl, as well.  See attached patch.

Logged In: YES 
user_id=7549

see 427644, also, for a spinning wheel cicular debate I had 
with myself :)