Bug: make install step tries to perform chmod on xowish even if not configured to build [PATCH]
Hi,
I got an error when building xotcl without tk and wish support where it tries to do a chmod on xowish (which of course doesn't exist at that point.)
This patch will fix the problem (as well as being self-explanitory as to why it should be applied). See attachment for patch; my email client seems to be translating white space, which would render the patch (and the resulting Makefile.in) inoperative.
Please let me know if the previous patch I sent for the tclsh location problem is similarly broken; I'll provide a fix if so.
Jim
-- Jam sessions community web site: http://jam.sessionsnet.org
On Thu, 8 Apr 2004 17:03:20 -0700 "Jim Lynch" jim@jam.sessionsnet.org wrote:
Hi,
I got an error when building xotcl without tk and wish support where it tries to do a chmod on xowish (which of course doesn't exist at that point.)
This patch will fix the problem
Actually no it won't, it's broke... needs " ; \ " at the line ends of the new chmod lines. Here's a better patch (attached).
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org
On Friday 09 April 2004 02:20, Jim Lynch wrote:
Hi,
I got an error when building xotcl without tk and wish support where it tries to do a chmod on xowish (which of course doesn't exist at that point.)
This patch will fix the problem
Actually no it won't, it's broke... needs " ; \ " at the line ends of the new chmod lines. Here's a better patch (attached).
Hi Jim,
i get the impression you are fixing things that are not broken in the general distribution. The configure stuff is defined to produces always a file xotclsh or xowish, no matter whether you compile with or without --with-xotclsh. Sounds wierd, isn't it? If you compile with the default values (without xotclsh), the generated file unix/xotclsh is a small tcl script with e.g. the following content:
#!/usr/bin/tclsh8.4 if {$argc == 0} { puts "Don't use [info script] as interactive shell! Use instead:" puts " /usr/bin/tclsh8.4" puts " package require XOTcl; namespace import ::xotcl::*" } else { package require XOTcl namespace import ::xotcl::* set argv0 [lindex $argv 0] set argv [lreplace $argv 0 0] incr argc -1 source $argv0 } This scriped is generated from xotclsh.in and requires a "chmod +x".
If you configure ... --with-xotclsh, the file unix/xotclsh is a true binary (a statically linked shell, also useful for these few platforms that have still problems with dynamic loading).
Producing a shell in form of a tcl script is useful for legacy applications, that still use xotclsh to call the xotcl scripts.
-gustaf
Gustaf Neumann wrote:
i get the impression you are fixing things that are not broken in the general distribution. The configure stuff is defined to produces always a file xotclsh or xowish, no matter whether you compile with or without --with-xotclsh.
This is just plain wrong. Drop the mega-binary idea. It is dead, dead, dead, dead. Tcl has had a very good dll mechanism for 7 years - all extensions should use it. So IMO Jim is fixing a configure system that *is* broken, at its very core design. You can do so much more with a pure extension, that should always be the default.
On Saturday 10 April 2004 22:51, Jeff Hobbs wrote:
Gustaf Neumann wrote:
i get the impression you are fixing things that are not broken in the general distribution. The configure stuff is defined to produces always a file xotclsh or xowish, no matter whether you compile with or without --with-xotclsh.
This is just plain wrong. Drop the mega-binary idea. It is dead, dead, dead, dead.
flame down, i know this, we have adressed this. per default, xotcl creates a file called "xotclsh", which is a tclsh script, and NOT the binary you are talking about. Do you oppose as well a tclsh script, having such a name?
Tcl has had a very good dll mechanism for 7 years - all extensions should use it. So IMO Jim is fixing a configure system that *is* broken, at its very core design.
look at our configure stuff, it has changend substantially in the last year. I would say, that i have personally invested over the last year more time into making xotcl's build system TEA compatible than into xotcl itself. We went through tough exercises such as building xotcl from outside directoris % mkdir -p /tmp/xotcl/unix % cd /tmp/xotcl/unix % ~/xotcl-1.2.0/unix/configure --with-all % make % make test % make install DESTDIR=/tmp as a result, xotcl was added to the tcl/tk distro for max OS X (Aqua). Correct me, if i am wrong, but I got the impression you are taking about the build system of xotcl, as it was about 2 years ago, and not about our current stuff.
-gustaf
This is just plain wrong. Drop the mega-binary idea. It is dead, dead, dead, dead.
flame down, i know this, we have adressed this. per default, xotcl creates a file called "xotclsh", which is a tclsh script, and NOT the binary you are talking about. Do you oppose as well a tclsh script, having such a name?
Not really, it's only a bit confusing. I do *prefer* that a user just knows that they can rely on 'tclsh' and then uses 'package require xotcl'. Note that the xotclsh and xowish that you build are not actually created +x, which would be an issue for use (at least not on build, maybe on install).
look at our configure stuff, it has changend substantially in the last year. I would say, that i have personally invested over the last year more time into making xotcl's build system
...
as a result, xotcl was added to the tcl/tk distro for max OS X (Aqua). Correct me, if i am wrong, but I got the impression you are taking about the build system of xotcl, as it was about 2 years ago, and not about our current stuff.
I had no issue with building 1.2 myself in the normal way that I expect (which is separate source and build dirs). I'm sorry that using TEA was so time consuming, but the earlier mods that I sent a year ago to your build system took me only a day to make. Of course, I ignored anything but the xotcl package because I believe everything else was "fluff". I think the xotcl 1.2 general organization is much improved though.
I see in your other message that you have the TEA3 stuff working well. I'm glad that you also find the less verbosity helpful - that was a goal. If you want to make a test build available, I will review it and send comments, but cannot do that until Thursday or Friday.
One of the reasons to version TEA_INIT was that upgrading should be easier. However, TEA3 is certainly not "settled". If there is something you don't like about it, or something that would make it easier from your point of view, please tell me. I haven't propagated TEA3 to a lot of extensions yet, so it's not "fully refined".
Note that the advantage of being "TEA compatible" is that it is much easier for distros to add you in (like Steffen did, and we are planning to do in ActiveTcl). It also means that you worry less about build system portability - let the core porters worry about that. For example, with the latest TEA you should be able to make a Win/CE build without any other code changes (assuming you don't call some evil Windows APIs).
Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos
-
Gustaf Neumann -
Jeff Hobbs -
Jim Lynch