Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#327 tclConfig.sh generation from makefile.vc

closed-accepted
7
2004-05-20
2004-03-04
Pat Thoyts
No

This patch fixes makefile.vc to generate a tclConfig.sh
file.

Discussion

  • Pat Thoyts
    Pat Thoyts
    2004-03-04

    makefile.vc ->tclConfig.sh patch

     
    Attachments
  • Pat Thoyts
    Pat Thoyts
    2004-05-13

    • assigned_to: mdejong --> davygrvy
     
  • Pat Thoyts
    Pat Thoyts
    2004-05-13

    Logged In: YES
    user_id=202636

    Reassigning as DG is really the makefile.vc person.

     
  • Logged In: YES
    user_id=7549

    This is an interesting marriage of concepts. this might need
    to be built for install rather than build. If one builds all
    possible flavors of Tcl: threaded, debug, static, memdbg, etc..
    tclConfig.sh is built to the same spot each time overwriting
    what was done last. The same would be true if we generated
    it for install assuming one places tcl85.lib (the import) in the
    same place as tcl85s.lib (the static), etc.

    The use of different names per flavor was cosen to avoid
    this. I don't what the resolve is. tclConfigs.sh and
    tclConfigt.sh?

     
  • Logged In: YES
    user_id=79902

    The tclConfig.sh file must always have the same name as
    that's the only way you can bootstrap the locating of the
    configuration. If people insist on putting different styles
    of build in the same dir it will break, but that's just
    tough since the other way round is really fscked up by design.

    The sensible thing is for people wanting to keep multiple
    installations of the same version of Tcl/Tk to do so by
    keeping them in different directory structures (e.g.
    c:/tcl/8.4static, c:/tcl/8.4threaded, etc)

     
  • Pat Thoyts
    Pat Thoyts
    2004-05-14

    Logged In: YES
    user_id=202636

    Personally I think all these values ought to be embedded in
    tclsh as done for Perl. However...

    the intent is to ensure that having built and installed tcl
    using nmake/cl that a user can expect to build TEA projects
    using msys + cl. For that we need a valid tclConfig.sh - one
    that matches the current installation (normally the release,
    dynamic, non-threaded).

    IMO if the file is slightly wrong I'm not to bothered. Its
    easy to fix if it's just removing a t suffix from a few
    names. However converting tclConfig.sh.in into something
    useful is more work that I imaging most people can be
    bothered with. In other words, I'd rather have a slightly
    broken version than no version.

     
  • Pat Thoyts
    Pat Thoyts
    2004-05-18

    Logged In: YES
    user_id=202636

    So can we add this in then?

     
  • Logged In: YES
    user_id=79902

    Revisit TIP#59?

     
  • Logged In: YES
    user_id=7549

    Added to HEAD.

     
    • status: open --> open-accepted
     
  • Pat Thoyts
    Pat Thoyts
    2004-05-20

    • status: open-accepted --> closed-accepted