RE: !! Take note !! CVS frozen !! RE: [Tcllib-devel] Tcllib Release

[Lars <lar...@re...>]

At 21.05 +0200 2005-10-10, Andreas Kupries wrote:
>>
>> so why not do some whirling, indeed? So
>> far I've mostly been dealing with the installer, but I thought I'd better
>> start typing things down before I forget...
>>
>> A first problem I had was that the installer doesn't handle permissions.
>
>Do you mean by that the installer gets confused by permissions when running=
,
>or that it does not set permissions on the files it installs ?

Primarily the former, but the latter would be good too.

>> I understand it probably can't, but there could be some advice in
>INSTALL.txt
>> on how to deal with this.
>
>We do have commands in Tcl for this, see "file attributes".

Oh, it's unusually inlined. Good! (Although practically it still wouldn't
have worked, as my designated target area was originally root-only
writable.)

>We will have to
>distinguish Windows and Unix, but otherwise we could set permissions. We
>should possibly discuss what would be good permissions.
>
>
>> Also it could try to catch the error (for me it
>> was the [file mkdir tcllib1.8] that failed first) rather than just error
>> out completely.
>
>I am not sure here. The tcllib1.8 directory is important for all packages.
>Erroring out does make sense IMHO.

I meant "catch in order to provide a more readable error message". In
particular if you're running in GUI mode, erroring out looks like an error
in the installer rather than an error in the use of it.

>> Next, I'd like to ask where the log ends up (when running the GUI
>> version).
>
>Nowhere. It is only shown in the GUI, but not written to file.
>
>> I got some curious error messages in the documentation-making-phase (for
>> snit_faq, I think), which however didn't stop the installation.
>
>Actually warnings. Some of the section/subsection titles are not unique.
>
>> I
>> thought I
>> could come back to it later, but after installation was complete wish jus=
t
>> exited, and then the information in the log window was no more. (I think
>> the error said something about a particular string not being a
>> valid return
>> code in the sv_se locale (???).)
>
>Eh ?? Interesting.

I thought so too. Copying the message does not appear possible either (text
widget bug, or just poor integration with system clipboard?), but retyping
it in this mail as it was appearing on screen it turned out to be:

Manpage warning (sectambig): unknown error code "sectambig" (for locale sv_s=
e).

>
> [Later, after having browsed the
>> installer.tcl code a couple of times, I see that the installer indeed jus=
t
>> quits when done. When working in GUI mode, it should first ask the user
>> whether (s)he wants to save the log window contents. An additional
>> alternative could be to dump the log window contents to stdout, though.]
>
>The installer can be forced into non-gui mode, using -no-gui. In that mode
>the log goes to stdout and can be captured.

Yeah, but then I'd have to specify a _very_ large number of command line
switches to get the locations right. I actually rather _prefer_ the GUI
mode.

>
>> Another curious thing is the default locations the installer
>> selects, which
>> had me confused for quite a while. In my system it wants to place
>> things in
>> /System/Library, despite /Library being more appropriate (e.g. being wher=
e
>> my wish is located). The logic that appears to be responsible for this is
>> that libpath is set to the last element of tcl_pkgPath, but is that
>> appropriate? Looking at how my tcl_pkgPath is constructed, it mostly goes
>> from specific (e.g. user-installed packages) to general (those provided b=
y
>> the OS vendor), so the things I install should rather go into some of the
>> early entries on this path.
>
>Hm. This might actually be platform dependent.

Almost surely the locations are, but wouldn't the search order "user, local
additions, vendor distribution" (which might be what in regular Unix?
Perhaps ~, /opt, /usr) be logical also on other systems?

>From your paths I see that
>you are on OS X. I tested this so far only on other Unix installations
>(Linux, Solaris, ...) and Windows. For these the path chosen is quite
>sensible.

Could this be because there isn't much to choose from? Checking the Tcl on
a local Linux machine, I find it is just /usr/lib (1 element, so the last
is also the first), whereas I here have as [join $tcl_pkgPath \n]:
/Library/Frameworks/Tcl.framework/Versions/8.4/Resources/Scripts
~/Library/Tcl
/Library/Tcl
/Network/Library/Tcl
/System/Library/Tcl
~/Library/Frameworks
/Library/Frameworks
/Network/Library/Frameworks
/System/Library/Frameworks

Lars Hellstr=F6m