Tcl Source Code

The current makefile for building Tcl 8.4a4 on Windows 
depends on exotic features of the Windows NT shell, 
making it unusable for people trying to build with 
Windows 95/98. I will try to list all the problems in 
this bug report.

makefile.vc and rules.vc are the files that need to be 
fixed.

This also applies to the makefile.vc and rules.vc for 
Tk.

Mark Follett

Logged In: YES 
user_id=7549

Great news.  On to feature enhancements...

Logged In: YES 
user_id=209568

Both Tcl and Tk build now on Win98. Thanks.

Logged In: YES 
user_id=209568

Both Tcl and Tk build now on Win98. Thanks.

Logged In: YES 
user_id=7549

Let me know how things are working. thanks.

Logged In: YES 
user_id=7549

changes committed to Tk now.  There's still some NT cruft 
left, but we're closer.  rules.vc is now an exact copy of 
the one from Tcl.  This is by design, actually.

Logged In: YES 
user_id=209568

Thanks David,  works good.  I see two more things that need 
to be done:

1) fix rules.vc for Tk--  it's pretty much the same as the 
Tcl one except it doesn't have the compiler tests.

2) fix makefile.bc for Tcl.  It is using '&' for combining 
multiple commands.

I was browsing through the Borland makefile and it looks 
fairly similar to the VC one.  I wonder if the VC and 
Borland makefiles could be combined into one....

Mark Follett

Logged In: YES 
user_id=7549

I decided to commit the changes anyways.  do an update and 
let me know how things are doing.  We're getting closer -- 
I'm sure of it.

File Added - 20121: patch.txt

Logged In: YES 
user_id=7549

Attached is a new patch that should fix everything.  If 
possible please test it.  Or I could just commit it, and 
try it from an update.  Let me know if you want me to just 
commit it.

Logged In: YES 
user_id=7549

Q: When does 152 lines of C equal a one liner from the 
shell?
A: doesn't work that way on Win9x, sorry.  Use the C 
instead.


I got the compiler test working:
D:\>nmakehlp -QQ
D:\>echo %errorlevel%
1
D:\>nmakehlp -MD
D:\>echo %errorlevel%
0

(-QQ is a non-existent option)
Next to add is the find command, give it a switch to tell 
the difference, and integrate it into rules.vc for a single 
pass build.  The nasty part is that I don't yet know where 
the intermediate directory is yet..  it's in the options I 
can't read because of the find.exe problem...  chicken/egg 
fun.  So this will have to build itself in the windows 
source directory.

Logged In: YES 
user_id=7549

I'm working on an all-in-one helper app, so we can stop 
hacking at the batch oddites for the moment.  I hope to 
alleviate all the funny stuff.  I'll be a few more days on 
it.

I had no idea how different Win9x was..

Logged In: YES 
user_id=209568

Submitted a patch for makefile.vc and rules.vc which uses 
the DJGPP redir program.

In addition to the changes for redirecting stderr and using 
a temporary text file to hold the input for find, I had to 
remove the use of '&' in makefile.vc for chaining multiple 
commands together. I also had to change the use of @if in 
the following code:

!if [@for %d in (temp.idb temp.pdb) do @if exist %d del %d]

You can only use '@' at the beginning of a line so I've 
just expanded it to:

!if [@if exist temp.idb del temp.idb]
!endif
!if [@if exist temp.pdb del temp.pdb]
!endif

Mark Follett

File Added - 20050: vcbuild.patch

Logged In: YES 
user_id=79902

Note re Test.bat behaviour described below: memories of my
DOS programming days say that "if errorlevel n" is defined
as behaving as "if errorlevel >= n"; I remember this,
because it made writing complex batch scripts an interesting
challenge... :^(

Logged In: YES 
user_id=209568

An ugly solution to this problem:

!if [echo "$(OPTS)" > options.txt]
!endif

.......code...........

!if ![find /i "static" options.txt > nul]

.......more code......

!if [del options.txt]
!endif

This will spit out some of find's output to the console 
even though we got " > nul" in there.

Mark Follett

Logged In: YES 
user_id=209568

Ack, the last post is nonsense. I must have been seeing 
things because 'return 1' works fine.

I think the problem is with piping echo to find. I tried:
  echo 123 | find "abc"
and
  find "123" words.txt
where words.txt contains "abc"

The first one will return 0, whereas the second will return 
1. I think it may be returning the exit status of echo in 
the first one.

Mark Follett

Logged In: YES 
user_id=209568

Nevermind about the batch file. The output is correct.
"if errorlevel N" will be true if the exit code is greater 
than or equal to N.

I wrote a little app (A) that would return the exit code 
and tried it out with nmake and had the same problem-- 
nmake would always get 0. I then tried (B) and it worked. 
In both situations the batch file test would give me the 
same output. I guess find is just returning the code 
instead of calling exit().

A: int main () {return 1;}
B: int main () {exit (1);}

Mark Follett

Logged In: YES 
user_id=7549

probably command.com.  At least on NT, cmd.exe is well 
hosed in numerous areas.  How can MS get away with this 
stuff?

Logged In: YES 
user_id=209568

Ok, on to the next problem:

All of the !if directives that use the exit code of find 
are broken. It appears that the exit code it gets is always 
zero. This is why it would always do a release build: it 
always takes the first !if branch which sets all the 
options to 0.

I wrote a batch file to test the output of find and got 
strange results.

Test.bat:
  echo "abc" | find "abc"
  if errorlevel 1 echo didn't find it.
  if errorlevel 0 echo found it.

  echo "abc" | find "123"
  if errorlevel 1 echo didn't find it.
  if errorlevel 0 echo found it.

Result:
  >echo "abc" | find "abc"
  "abc"

  >if errorlevel 1 echo didn't find it.

  >if errorlevel 0 echo found it.
  found it.

  >echo "abc" | find "123"

  >if errorlevel 1 echo didn't find it.
  didn't find it.

  >if errorlevel 0 echo found it.
  found it.

In the second case errorlevel is 0 and 1 at the same time! 
Dave, please try this out and let me know if you get the 
same output.

I don't know if the problem is with find, nmake, or 
command.com.

Mark Follett

Logged In: YES 
user_id=7549

cl.exe runs happily detached, so we can do this no problem.

I'll work on the c code for this.  It won't take too much 
work for me to do it.

Logged In: YES 
user_id=7549

A helper app is a good idea.  redirecting is easily done 
from C and we don't to look much farther than Tcl's own 
cat.c and stub16.c for examples.

Logged In: YES 
user_id=209568

Rules.vc does some compiler tests which try to redirect 
stderr to stdin. After doing some searching on the net I've 
concluded that this is impossible to do with the Windows 
95/98 command.com.

Possible solutions would be:
1) Figure out a way to do the compiler tests without 
redirecting stderr. From David G's comments on 
comp.lang.tcl this doesn't appear to be possible.

2) Distribute a tiny executable with Tcl which will 
redirect stderr. DJGPP has a tool called redir.exe that 
will do this. It is described in the FAQ here:

http://www.delorie.com/djgpp/v2faq/faq6_15.html

Mark Follett