Tcl Source Code

According to the naming conventions used in TclPro, 
the 'd' suffix denotes executables files (exe, dll, lib) built 
for symbols.

Is this now different.  Are there any other upcoming 
naming convention changes such as 'r' to denote a 
threaded build?  makefile.vc uses 't' for threaded.  No 
suffix was added for memory debugging, but win/tcl.m4 
is adding one.

Logged In: YES 
user_id=7549

Let's call this closed and just accept the odd behavior.

Logged In: YES 
user_id=7549

I haven't check lately, but TEA with --enable-threads should 
suffix with 't'.  I like the idea, myself.

memdbg only without symbols might be still suffixing with 'g' 
and when loaded, $tcl_plaform(debug) is 0, so the wrong type 
extensions are loaded to match the options.

Logged In: YES 
user_id=99768

The 'd' appears to be changed to the 'g' throughout.
All that I did was to make 'makefile.vc' (and 'rules.vc')
track Mo's change to 'Makefile.in'.

Whether this fixes the problem, I can't say. I really
don't want to get into the arguments about what's
right.  The 'd' didn't mean 'symbols' as much as it meant,
'linked with msvcrtd, don't mix with stuff linked with msvcrt
or libc or libcd'.

David, is this resolved? If so, can we close it out?

Logged In: YES 
user_id=72656

Didn't Kevin correct these?

Logged In: YES 
user_id=7549

Oh now things are really messed up.  At the next import I do 
at work, I'm undecided whether I have to change everything to 
now to conform to this new 'g' thing.  And that's not just a 
days work.  I can rename all the TclPro1.4.1 library files...  
and redo all the 2 dozen .dsp files...  Oie vei!

THIS SHOULD HAVE BEEN DONE SIX YEARS AGO!

I don't like this change.  I really don't.  It's too much pain for 
no gain.  At least no gain for me.

Andreas:
>TclPro used the 's' modifier for the true static libraries. I
>don't the exact meaning of the 'x' TclPro uses in some
> places.

A static library but compiled to use the dynamic runtime.  
IOW, itcl32x.lib is a static library but wants to link with 
msvcrt.lib (the import library for the dynamic runtime).

Logged In: YES 
user_id=32170

Yes, it should go into 8.4.2, otherwise debug builds are 
broken!

Logged In: YES 
user_id=72656

Additionally, Andreas notes that configure.in uses a check of 
DBGX = "d" (line 342 and just under) to set the debug stuff for 
the rc building (which is minor, but should also be corrected).

Logged In: YES 
user_id=72656

OK, the easiest solution is to correct tcl/win/rules.vc to 
use 'g' instead of 'd' for debug builds.  That doesn't address 
other issues, but it makes things homogeneic across build 
types.  Is this something that should squeeze into 8.4.2?

Logged In: YES 
user_id=75003

static - No. If on windows TEA2 currently builds itcl32.lib, this 
can either be the import library for the DLLL in a shared build, 
or the name of the static itcl library in a static build.

TclPro used the 's' modifier for the true static libraries. I don't 
the exact meaning of the 'x' TclPro uses in some places.

Logged In: YES 
user_id=79902

Ugh.  We need a policy here.
I reckon "distinguish if we *must* but otherwise not" should
be our guiding principle.
We must distinguish debug on Windows.  It's almost certainly
a good idea to distinguish threaded on all platforms
(purists might argue not, but the realist in me is
suspicious we can't be pure here.) Anything else seems
unnecessary to me (static is obvious from the extension,
yes?  And the 'x' specifier feels like something that is so
ugly we should pretend it doesn't exist...)

Given the above, we need a 'd' suffix on Windows only, and a
't' suffix everywhere.  Yes?

Logged In: YES 
user_id=32170

Can we resolve this before 8.4.2 is released, so debug 
builds actually work and can run against the test suite?

Logged In: YES 
user_id=7549

If compiled for memdbg, tclreg11g.dll gets made, but because 
tcl_platform(debug) won't be set in this case, tclreg11g.dll 
won't get loaded by it's pkgIndex.tcl.  Is this proper behaviour 
or a bug?

Logged In: YES 
user_id=7549

I can make the 'd' to 'g' change in makefile.vc quite easily, but 
we might want to take some of my ideas over to the TEA 
build, too.  ${DBGX} could be more generalized to mean "the 
name suffix which give the output executables special 
meaning".  I think it might be benificial to add a suffix for
--enable-threads so both threaded and non-threaded can live 
in the same install point.  I propose the following:

tcl84tsgx.(a|lib)

The 'tsgx' part broken down means:

t = has thread support
s = static library
g = symbols, compstats or memdbg
x = use the dynamic msvcrt.dll instead of the static libcmt.lib

Logged In: YES 
user_id=72656

'g' has always denoted the debug builds on Unix, and 'd' on 
Windows.  I don't know why they couldn't agree upon a 
convention when first creating the TEA stuff ...

Logged In: YES 
user_id=75003

Jeff did the work on the build system introducing the change. 
He can answer the questions better than I.

I was just tripped on this when I created debug builds of 
ActiveTcl, etc. and did partial updates of some files.

File Added - 34869: patch.txt