Tcl Source Code

View Ticket
Login
Ticket UUID: 436116
Title: TIP#60 patch
Type: Patch Version: None
Submitter: nobody Created on: 2001-06-25 15:38:25
Subsystem: 53. Configure and Build Tools Assigned To: davygrvy
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2008-11-30 01:26:14
Resolution: Out of Date Closed By: dkf
    Closed on: 2008-11-29 18:26:14
Description:
With the material submiited here it is possible to build Tcl 8.3.3 with the current 
Borland compiler.
IMHO there are two points where someone more knowledgable than me should have
a look:
1) The typedef for ClientData
The original version did a test

  #   if defined(__STDC__) || defined(__cplusplus)

when defining the typedef ClientData, which does not work well for the Borland compiler:
- __cplusplus is not defined (or else the regexp-package will not compile)
- __STDC__ is only #defined if you set '-A' for strict ANSI compatibility. But then the 
  compiler is *really* strict and thus quite a few files will not compile for various reasons 
  (e.g. a '//' comment in one of the Windows header files).

So you're stuck with 'typedef int *ClientData;' - which in turn forces an ugly type cast 
in the function 'Tcl_CreateThread' for the parameter 'proc' in the call to 
_beginthreadex (file tclWinThrd.c).

But then I wondered: Are we asking the appropriate question? We ask:
    Is it a (strict?) ANSI or a C++ compiler?
when all we want to know is whether it supports the 'void' key word or not. Hence 
the #define KNOWS_VOID in tcl.h.


2) Borland #defines more error codes in <errno.h> than does VC++. This leads to a 
clash in error definitions in tclWinPort.h when EDQUOT is #defined as 49, because
the last #define in Borland's errno.h is
  #define ENOTEMPTY 49    /* Directory not empty              */
With these two definitions tclPosixStr.c will not compile.
I changed the #define for EDQUOT to 69 because in some other header file I found the
same definition to achieve compilation.
However there might well be better choices.

I hope that this description makes sense and that the attached diff file is what you need.
Best regards
Helmut Giese
User Comments: davygrvy added on 2004-10-26 23:21:38:

File Added - 106562: patch.zip

davygrvy added on 2004-10-26 23:19:19:

File Deleted - 7772:

davygrvy added on 2003-12-14 06:10:52:

File Added - 70485: exports.txt

davygrvy added on 2003-12-14 06:09:40:

File Added - 70483: exports.txt

davygrvy added on 2003-12-14 06:07:10:

File Added - 70480: patch.txt

davygrvy added on 2002-09-01 07:27:16:

File Deleted - 30218:

davygrvy added on 2002-09-01 07:26:32:

File Added - 30219: patch.txt

davygrvy added on 2002-09-01 07:24:45:

File Deleted - 10469: 



File Added - 30218: patch.txt

davygrvy added on 2001-11-07 13:21:49:
Logged In: YES 
user_id=7549

I'll call this closed.  The TIP is dead, but doesn't matter bcc32 5.5+, only the older ones.

davygrvy added on 2001-09-08 07:27:01:
Logged In: YES 
user_id=7549

The maintainence utility that goes with Borland is called 
make.exe.  It's a Borland product.  It's installed with the 
archive refered to as "free commandline tools".

'nuff said.

If later on, we want to abstract a common denominator to a 
makefile.win, then launching either nmake.exe, make.exe, or 
wmake.exe with appropriate rules, we can.  I know you think 
the whole world should run GNU tools, but guess what?...

**** They aren't included with all IDE/dev products. *****

I mentioned makefile.bc in your TEA v2.0 TIP, and you got 
all worried.  Well, here it is.  go make some autoconf 
rules with it.

PS. wmake.exe referes to Watcom, which I'm working on as I 
type this.

mdejong added on 2001-09-07 22:24:29:
Logged In: YES 
user_id=90858

I have to admit, I don't think it is a good idea to
add a new makefile.bc file. Why can't Borland support
be added using the ./configure and Makefile.in build
system? There has been quite a bit of work done to
get things working with VC++ and gcc under Windows.
Adding a new Makefile will just lead to more duplicated
work down the road.

davygrvy added on 2001-09-07 09:03:12:
Logged In: YES 
user_id=7549

TIP inserted into system and newer patch file ready to go.

davygrvy added on 2001-09-07 08:46:18:

File Deleted - 10429:

davygrvy added on 2001-09-07 08:46:17:

File Added - 10469: patch.txt

davygrvy added on 2001-09-06 12:42:41:
Logged In: YES 
user_id=7549

wheee!

makefile.bc commited.  Looking good.  Not perfect yet.  All 
changes in this patch report were commited to the HEAD not 
to the core-8-3-1-branch.

Time to get the TIP ready...

davygrvy added on 2001-09-06 12:09:17:

File Deleted - 10426: 



File Added - 10429: patch.txt

davygrvy added on 2001-09-06 12:09:16:
Logged In: YES 
user_id=7549

I like this proposed patch better.  More complete..

davygrvy added on 2001-09-06 09:50:03:

File Added - 10426: patch.txt

Logged In: YES 
user_id=7549

Here's a new patch for what I think the EXTERN macro should 
do.

davygrvy added on 2001-09-06 08:43:44:
Logged In: YES 
user_id=7549

as of <now>, everything is in except for the new 
makefile.bc and the errno stuff.  I want to do a TIP 
regarding changing the EXTERN macro.  For example, what is 
this for MSvc++:

  __declspec(dllexport) __cdecl int func (int a, int b);

needs to be this with borland:

  int __cdecl __export func (int a, int b);

The order of the attribute needs to be after the return 
type.  Watch for a TIP soon.

note to self: not sure what to do about the errno stuff 
yet...

davygrvy added on 2001-09-06 08:16:45:
Logged In: YES 
user_id=7549

I'm starting to put together a TIP about changing the 
EXTERN macro.  Borland will need some partially ugly fixes 
put into tcl.h and genStubs.tcl.

davygrvy added on 2001-09-06 08:13:47:
Logged In: YES 
user_id=7549

Hi Don,

Not actually true.  1.10 was a mistake, but 1.11 a few 
minutes later has the changes above the marker:

/* !BEGIN!: Do not edit below this line. */

dgp added on 2001-09-06 07:55:06:
Logged In: YES 
user_id=80530

I'm guessing that this report is related to the changes
checked in to generic/tclPlatDecls.h on Sept-05-2001.

Note that those changes will be overwritten the next time
someone does 'make genstubs'.  The script tools/genStubs.tcl
needs to be updated to generate the changed *.h file(s).

davygrvy added on 2001-09-02 17:27:24:
Logged In: YES 
user_id=7549

I guess I got assigned to this, eh?

Ok, I got the "free commandline tools" here.  I'll look 
into it.

nobody added on 2001-06-25 22:38:25:

File Added - 7772: patch.txt

Attachments: