Mailing List Archive

I just see, that Nick has answered already, so I only add a few words...

>>>>> "sb" == Steffen Beyer <sb@sdm.de> writes:

sb> Ananda M. Kar (ananda@cs.utexas.edu) wrote:
>> I just installed the Tk-b8. I'm using perl which is installed properly but not
>> in "/usr/local/bin". Whenever I try the basic demo "perl ./basic_demo" I
>> encounter the following error.

[...]

>> What am I doing wrong or how do I fix it ??

If Nick renamed basic_demo to test.pl or t/basic_demo.t, all would be
well. You could say 'make test' and the Makefile would call

perl -Iblib test.pl

Note the -Iblib. You have to use it as long as perl is not
installed. So you say

perl -Iblib basic_demo

>> Thanks

>> Ananda

>> --
>> Ananda M. Kar |(H)458-9754 | URL: http://www.cs.utexas.edu/users/ananda/


sb> I've had the same problem because on our machines, we install all packages
sb> in a separate "/opt" (for "optional" software) subtree, where each package

[...]

sb> All this is impossible to do when every package installs its binaries
sb> in /usr/local/bin (possibly overwriting other binaries with the same name,
sb> in this process!), because after some time, it's almost impossible to know
sb> to which package a binary belongs to, and almost impossible or at least im-
sb> probable to be sure that you removed ALL binaries belonging to a package you
sb> want to de-install.

I admit, the $Config{installbin} directory is a weak point but it's a
common problem to all software installations. You can of course check
the INSTALLBIN parameter of MakeMaker and do your own thing.

If you have called make install ever, then you find at least a
complete list of all installed files in a file called something like
/usr/local/lib/perl5/IP22-irix/auto/Tk/.packlist. The final form of
the packlist is being discussed on the makemaker mailing list, and
will probably end up in a much completer dump of the module
configuration.

sb> (Why would you like to de-install packages, in the first place? Because some-
sb> times you only want to test them, and when they don't do what you would like
sb> them to do, you want to get rid of them, because you can't afford to waste disk
sb> space. The other reason is that packages evolve, and you might want to install
sb> the latest version. However, (as was the case with perl 4 / perl 5), not
sb> necessarily all binaries are preserved in the update, or new ones are intro-
sb> duced. That way, your /usr/local/bin ends up to be trashed with zombies.)

sb> I'm writing this in such detail because it might be a useful concept for others
sb> as well, and software providers should think it over if they don't want to
sb> support it - till now, installing additions for Perl is a mess!

I agree. But as you see with the .packlist, it is being worked on.

sb> My workaround to the problem was to change all the "#!/usr/local/bin" to
sb> "#!/opt/bin/perl5" (which is the correct path and name for us) in ALL the
sb> perl scripts (hairy, I know!) in the subdir where the binaries are located
sb> after the "make install", and all the "unshift(@INC, qw(./blib .))" and the
sb> like in all the scripts in the "bin" and "lib" subdirectories to the proper
sb> (absolute!!) path. (By the way, in my opinion, this is a bug in Tk-b8: It

I'm not speaking for Tk, I'm the maintainer of MakeMaker. MakeMaker in
general does, of course, not assume the current directory being the
final directory. ./blib is the place where everything is moved to
during the build. It's nothing but a parking place to give room to the
compilation phase.

sb> assumes that the current working directory will be the package's directory
sb> when something in the package is called. I don't think that this is the case,
sb> so there should be ABSOLUTE (not relative!) paths to the "blib" subdirectory!!)

I disagree. 'make install' has to be done with absolute pathnames but
not the testing phase. The testing phase should be independant of it's
location in the file system. If the filesystem changes beneath it, it
shouldn't do any harm. Exactly folks who try to be more clever than
what the installation manuals suggest regularly get bitten after a
while, because they forget to correct some pathnames and end up with a
mixture of Tk-b6, b7, and b8 somewhere.

I don't try to be more clever than the user, but at least the whole
thing is well documented, so you know, what you may expect. blib is
the parking place, and the final places have with INSTALLPRIVLIB,
INSTALLARCHLIB, INSTALLBIN, and with MakeMaker 4.23 also
INSTALLMAN1DIR and INSTALLMAN3DIR really a lot of configurable
parameters for the installation. Alas, forgot PREFIX :)

sb> Actually, I'm still working on this because I just installed Curses and Tk-b8
sb> last friday; I'm considering copying the "blib" subdir to another, more
sb> appropriate location to resolve the problem more elegantly.

Elegantly? That's definitely a NoNo. ./blib mixes all 5 above
mentioned parameters onto one directory. You're doing the wrong thing
here. Read the MakeMaker documentaion. Watch CPAN, I'm going to
release version 5.00, a much improved one, this week and currently
4.23 is on the archives. Worth a look.

sb> In case I find out more about this, I'll let you know.

sb> Hope this helps a little!

Ditto!

sb> Best regards,
sb> --
sb> Steffen Beyer

andreas

>>>>> " " == Nick Ing-Simmons <Nick.Ing-Simmons@tiuk.ti.com> writes:

> The snag with 'make test' for Tk is that until clever self-testing that
> Tcl/Tk *had* (it is broken in tk4.1) then pass/fail is not easy to report.

Sure. With an interactive package, no way.

> Note that the -Iblib should not be necessary becuase of all the
> @INC munging that demos do.

Ooops, didn't know that.

> I will put/link the best single test/demo/whatever to test.pl in Tk-b9.

Good idea. I usually show Tk/demos/widget to my visitors.

> Apart from having a .PL form of every installed executable is there
> an approved way to fill in the #! line?

Nope, PL files are the way it is designed currently. But I'm open to
suggestions.

andreas

In <199510230908.AA14804@bibb.bi.sdm.de>
On Mon, 23 Oct 1995 10:08:19 +0100 (MET)
<sb@sdm.de> writes:
>
>My workaround to the problem was to change all the "#!/usr/local/bin" to
>"#!/opt/bin/perl5" (which is the correct path and name for us) in ALL the
>perl scripts (hairy, I know!) in the subdir where the binaries are located
>after the "make install",

Fair enough, all the "binaries" should really have that done
by install process as Makefile.PL already knows path to perl executable.

>and all the "unshift(@INC, qw(./blib .))" and the
>like in all the scripts in the "bin" and "lib" subdirectories to the proper
>(absolute!!) path.

That should not be necessary, correct 'fix' for install process
is to *remove* those @INC hacks.

>(By the way, in my opinion, this is a bug in Tk-b8: It
>assumes that the current working directory will be the package's directory
>when something in the package is called.

Those relative paths are there so that you can run all the demos etc.
from the *BUILD* directory *BEFORE* you do an install.
This allows testing - and if you don't like it you can avoid uninstall
by not installing!

When you do do an install all the things needed are copied to the
'right' sub-directory of the include directory compiled in to the perl
you use to build the Makefiles.

>I don't think that this is the case,
>so there should be ABSOLUTE (not relative!) paths to the "blib" subdirectory!!)
>
Once installed that is what you get.

In <199510241629.RAA07165@anna.mind.de>
On Tue, 24 Oct 1995 17:29:57 +0100
Andreas Koenig <andreas.koenig@mind.de> writes:
>I just see, that Nick has answered already, so I only add a few words...
>
>If Nick renamed basic_demo to test.pl or t/basic_demo.t, all would be
>well. You could say 'make test' and the Makefile would call
>
> perl -Iblib test.pl
>
>Note the -Iblib. You have to use it as long as perl is not
>installed. So you say
>
> perl -Iblib basic_demo
>

The snag with 'make test' for Tk is that until clever self-testing that
Tcl/Tk *had* (it is broken in tk4.1) then pass/fail is not easy to report.

Note that the -Iblib should not be necessary becuase of all the
@INC munging that demos do.

I will put/link the best single test/demo/whatever to test.pl in Tk-b9.

Apart from having a .PL form of every installed executable is there
an approved way to fill in the #! line?

>>>>> "sb" == Steffen Beyer <sb@sdm.de> writes:

sb> Hello Andreas Koenig, in a previous mail you wrote:
>>
>> I just see, that Nick has answered already, so I only add a few words...

sb> Oooops - I didn't find that one in this mailing list?!

sb> What happened?

I just sent you a copy in PM.

[...]

sb> Yes, but OUR concept (mentioned above) is really CLEAN, whereas the installing
sb> of one package (Tkperl, for instance) INTO ANOTHER (Perl, in this example) is
sb> not! (Since extensions are going to lie INSIDE the Perl distribution tree,
sb> in the "ext" SUBdirectory! AND its binaries (and libs) are copied to the
sb> SAME directory as the Perl binaries (and libs, respectively)! (That's the
sb> worst part!)

Nobody has told you to install Tk below the perl source
tree. Certainly not. We are tired of telling you: please build, test,
and install the package anywhere you want, but let the ext/ directory
of the perl distribution alone. I don't know, why we have to repeat
that again and again.

You wouldn't build your shell within the perl source tree either, would you?

I'm working hard to let you build Tk even within the perl source. One
day, maybe sooner, maybe later, we won't have this discussion
anymore. It's just plain damn hard to have it happen.

sb> THAT'S not clean! How can I de-install a version of an extension properly,
sb> this way? The extension should also reside (including the binaries, libs etc)
sb> in a directory tree OF ITS OWN! That way I could easily de-install a certain
sb> version and install the newest version, for example.

It does. (Except for installed binaries, we have discussed that part
already). Have you ever read the regularly posted modulelist to see
how carefully we think about the namespace?

sb> Perl should be told (configurably) in which central directory to look for the
sb> LINKS to the extension's SUBTREES (of their OWN)! (And look THERE for the exe-
sb> cutables (.pm and .so and the like) of the package!)

Pardon? Somewhere you will have to tell it perl, and then again untell
it. We're managing this with directory trees.

[...]

>> Read the MakeMaker documentaion.

sb> Never heard of it before. Where can I find it?! Hurry!!!!! ;-)

type

perldoc ExtUtils::MakeMaker or
man ExtUtils::MakeMaker

>> Watch CPAN, I'm going to
>> release version 5.00, a much improved one, this week and currently
>> 4.23 is on the archives. Worth a look.

sb> Ok, where to find and what filename?

You find out more about CPAN at
ftp://ftp.funet.fi/pub/languages/perl/CPAN/CPAN

On any CPAN site you will find three interesting index files:

./authors/00whois.html Who is who
./modules/00modlist.long.html Tim's module list, mentioned above
./modules/01modules.index.html The most useful file for quick searches

and MakeMaker currently here:

./authors/id/ANDK/MakeMaker-5.03.tar.gz
./modules/by-module/ExtUtils/MakeMaker-5.03.tar.gz
./modules/by-category/03_Development_Support/ExtUtils/MakeMaker-5.03.tar.gz


sb> Thanks for dedicating me so much time in answering my posting so thoroughly!

Ahh, thanks for reading it so carefully for 2 weeks ;-)

sb> Best regards,
sb> --
sb> Steffen Beyer

andreas