Mailing List Archive

Excerpts from the mail message of dk smith:
) Below are more comments

Thank you. I've copied my response to the dist-3 users' list
since about half of this deals with that. Follow-ups should
probably omit the dist-3 list unless the content warrants
their continued attention.

) And, if anyone has some suggestions for me that would get me closer to
) using perl instead of building it, then I would be very appreciative.

Yes, one. You need more -L ld flags. More on this later.

) The -s option is not listed in the usage info. I could not tell any
) diff btwn -de and -des. I still rcv'd tons of stuff spewing across the
) screen.

-s does omit quite a bit of output but not nearly enough.

) make distclean
)
) Cleaning the distribution should either remove config.sh or move it
) to a safe place like 'config.sh.date'.

"make realclean" doesn't touch config.sh but:

clobber: realclean
rm -f config.sh cppstdin

distclean: clobber

"make distclean" does.

) Please note that the statement:
) @echo "Note that make realclean does not delete config.sh"
) does not make it to stdout in any of the cases that I experienced.
) In fact, I've never seen the message until I started poking around
) looking for something like it.

I see no way for either of the above two items to be so, so I
suggest you check into why this is this way for you and we'll
try to fix it. Perhaps you have too old a copy of Perl? Are
you building perl5.001m? (The "m" is important.)

) What exactly does the variable 'incpath' do?

No, incpath is for some obscure C compiler and is almost never
used (as far as I can tell).

) I wuold like to
) know what variables affect the "-I/some/dir/path" option that
) is given to the compiler.

Nothing changes this default value other than hints files (and
some really obscure stuff noted above which is best ignored).

) Comments or some other form of documentation
) would be helpful.

You probably should fetch "dist-3" which contains metaconfigure
which generates the Configure used in Perl (and many other places)
if you want documentation on this type of stuff.

I wouldn't be surprised though if there were documentation on
some of this in the Perl distribution that I didn't know about.
I don't know where you'd want us to put it so that you would
have found it when you wanted it. We could have Configure tell
you more about how this is done but Configure already seems to
be telling most people way too much so I'm not sure how to best
address this.

Perhaps you'd like metaconfigure to include comments from the
components that are combined to build Configure? Do any long-
term dist uses know if this has been discussed before?

) Is the variable 'usrinc' useful? Again, a comment would have been
) helpful.

'usrinc' is mearly an optimization so Configure can look for
certain very common include files there first. When this fails
(or if it isn't expected to succeed), Configure just compiles
short test programs using whatever "-I" options you gave and
uses this to figure out stuff about include files.

) If I am using gcc-2.7.0 must I placed the path to my
) fixed-includes here?

Hmmm. Probably would work either way but I'm not sure.

) <<From experimentation I learned that Configure expects only one
) path in the variable 'usrinc'. Giving it two paths of the form
) '/some/path/one /some/path/two' causes an error in the Configure
) script. I also conclude that 'incpath' does nothing.>>

Perhaps the prompt for usrinc should be a bit more explicit and
say "What is the [single] primary directory where most or the
system include files that you want to use will be found?" ??

) For some reason, when gcc is linking (I assume it's linking) the
) library -ldb cannot be found; causing the build of miniperl to
) fail. This comes immediately after "ar *.o *.o, etc".
) My config.sh file has the following variable defined:
)
) libpth='/usr/lib /usr/ccs/lib /opt/sww/lib /opt/gnu/lib
) /opt/gnu/lib/gcc-lib/sparc-sun-solaris2.4/2.7.0'
)
) Why does this fail when the file exists at: /opt/sww/lib/libdb.a

"libpth" just tells Configure where to look when it is searching
for the libraries in "libswanted" in order to:
see if you have that library at all
then
[possibly] run "nm" on the library to see if you have this or
that subroutine/global defined in any or your libraries

Which libraries actually get included is controlled by the -L
options you give. Specifying a library in "libwanted" _does_ cause
an "-l" option to be defaulted into the ld flags. But, specifying
a directory in "libpth" does _not_ cause -L to be added to "ldflags".
It is up to the user to add -L options to ldflags for any directories
in "libpth" that require them ("/usr/bin" will be in "libpth" but
you don't need "-L/usr/lib" in "ldflags").

I thought Configure described this to the user, but I don't see it
now. Automating default -L options based on libpth is one of the
more requested enhancements. I thought it may have already been
done but it doesn't appear so.

) installman1dir='/usr/man/manl'
) installman3dir='/opt/sww/lib/perl5/man/man3'
)
) It implies the installation process will place some man pages in
) with my Solaris distribution's man pages (installman1dir) and
) some a bit closer to my preferred location but still not where
) I'd expect them to go. I don't want to litter my Sun distribution
) with non-distribution files if I can avoid it.

I completely agree. Tom Christiansen is pretty adamant that the
man pages must be installed where they will work by default for
the majority of the clueless masses that might install Perl.

I'd rather have three divisions here. "man1" for perl.1, a2p.1,
and s2p.1 *only*. "manp" for the remaining perl*.1 files (manp
and man1 could default to the same place, of course, but
"perlfunc" is not a command and so it doesn't belong in
man1/perlfunc.1, IMO). "man3" for the modules.

I'd also like "make install" to *ask* before it installs the
man pages (since I don't think I could get consensus to split
"make install.man" out from "make install" as has been requested
before) and include the destination directory in the prompt (in
case you did the non-interactive Configure).

Perl also needs an "uninstall" script. This has been discussed
before but it probably hasn't gotten far since then.

) I'm also not sure what, if any, significance I should place
) on the 'manl' (man ell) leaf directory. I think that the man pages
) should be installed in ${INSTALL_PREFIX}/man. So, for
) the variables above, I supply the definitions:
)
) installman1dir='/opt/sww/man/man1'
) installman3dir='/opt/sww/man/man3'
)
) Don't know, yet, if this will work due to my inability to build
) the program... Though, the config.sh file does pick up the correct
) values, it appears.

Some systems use /usr/man/manl for the man pages for "local"
commands. Other use /usr/local/man/man1 for "local" commands and
allow /usr/local/man/man? for "local" other things. I find it
better to not mix my "local" things under the same directory
tree as items distributed with the OS.

Hope that helps. Maybe some of us will lose our jobs *and* win
the lottery and more of these improvements will get made.
--
Tye McQueen tye@metronet.com || tye@doober.usu.edu
Nothing is obvious unless you are overlooking something
http://www.metronet.com/~tye/ (scripts, links, nothing fancy)

Excerpts from the mail message of Andrew Cassin:
)
) > "make realclean" doesn't touch config.sh but:
) > ) @echo "Note that make realclean does not delete config.sh"
) > ) does not make it to stdout in any of the cases that I experienced.
)
) Sounds like a broken make to me '@echo: command not found' :-)

Actually it was just a missing "-". A "make realclean" on one
of the subdirectories was failing because the previous configure
process hadn't gotten far enough for the Makefile to have been
created there yet. Unfortunately, the line to that started
with "@" and not "-@" so the error aborted the rest of the
original "make realclean" (and "make distclean") so config.sh
was never removed and the @echo was never reached.

) This library handling stuff does seem painful for many people. Would it
) be possible to extend Configure with a unit that attempts to resolve library
) & library path problems near the end of the Configure script?

I was thinking of just having ldflags default to include -L
options for all libraries listed in libpth except /lib and
/usr/lib. Then the user is just responsible for deleting a
few if they really need to instead of being responsible for
adding them all in.
--
Tye McQueen tye@metronet.com || tye@doober.usu.edu
Nothing is obvious unless you are overlooking something
http://www.metronet.com/~tye/ (scripts, links, nothing fancy)

On Fri, 8 Sep 1995 Nick.Ing-Simmons@tiuk.ti.com wrote:

> Could we not force the 'important' questions to the top by inserting
> an artificial dependancy on them?

For perl5 for most of the 'important' questions, the answer is,
effectively, yes.

Doing it correctly in full generality for all metaconfigured packages
is harder. For perl5, I've privatized a few metaconfig units already
anyway, and I know what order they're coming out in now, so I can
"cheat" a little and get the desired effect.

That's been on my ToDo list for a long time, and I know what I need
to do; I just haven't had time to do it. Someday soon. I hope.

Andy Dougherty doughera@lafcol.lafayette.edu
Dept. of Physics
Lafayette College, Easton PA 18042

Quoting dk smith:
:What exactly does the variable 'incpath' do? I wuold like to
:know what variables affect the "-I/some/dir/path" option that
:is given to the compiler. Comments or some other form of documentation
:would be helpful.

This variable was introduced mainly to be able to cope with MIPS systems.
On those beasts --which (un)fortunately I have once used as a workstation--
you can have both USG or BSD flavors depending on some variable environment.
Hence the explicit testing for MIPS system in Configure, and the special
lookup for the libc.a using $incpath/usr/lib, since, on mips, looking
for symbols in /lib/libc.a would cause disasters. In that case, incpath
is set to /bsd43 for the BSD flavor or just empty for USG flavor.

Anyway, that variable is just used internally by Configure and no user
setting is possible (nor warranted).

:Is the variable 'usrinc' useful? Again, a comment would have been
:helpful. If I am using gcc-2.7.0 must I placed the path to my
:fixed-includes here?

That variable is used occasionally within metaconfig units to
point to the proper include by referencing "$usrinc/whoami.h" for
instance. Nowadays, metaconfig as a more powerful unit to lookup
include files by using the C compiler directly. But that requires
to load the cc.U unit and some other stuff in, and some units
just don't want to do that.

:<<From experimentation I learned that Configure expects only one
:path in the variable 'usrinc'. Giving it two paths of the form
:'/some/path/one /some/path/two' causes an error in the Configure
:script. I also conclude that 'incpath' does nothing.>>

In the light of the above explaination, you're right and wrong,
in that order ;-)

Regarding the order of questions in the Configure script:

They are determined by the topological sort used by the 'make' program
of the machine on which metaconfig is run to produce Configure.

Metaconfig tries to put i_*.U units at the end of the script by
sorting the list of wanted symbols that are fed to 'make' for
dependency resolution. It also tries hard to put the d_*.U questions
together. That's done by relying on that implicit naming convention.

Other units may potentially ask the user some question. The place
of those units is determined by the amount of information they need
at the point they have to guess a reasonable default. Trying to
grouping them topologically is possible but it is not guaranteed
that no interleaving unit will be placed between those questions,
since the topological order is no a full order in the mathematical
sense.

Besides, I *never* use the -d switch the first time I run a Configure
script because I prefer have a good look at the questions asked to
me to be able to figure out what could possibly have gone wrong later
on. So having the questions groupped is not a matter of importance to
me, although I understand it might be to others.

Since there are some other topics rated with an higher priority in
my TODO list, the best thing to do would be for someone with a
high enough motivation to grab the latest dist-3.0 distribution and
try to implement this grouping scheme.

Raphael

In <14261.810549786@memphis.grenoble.hp.com>
On Fri, 08 Sep 95 10:43:06 +0200
Raphael Manfredi <ram@hptnos02.grenoble.hp.com> writes:
>
>Regarding the order of questions in the Configure script:
>
>They are determined by the topological sort used by the 'make' program
>of the machine on which metaconfig is run to produce Configure.

Could we not force the 'important' questions to the top by inserting
an artificial dependancy on them?

E.g. a rest-of-defaults-probably-okay unit which depends
on the units most likely to need user input.
Other units then depend on rest-of-defaults-probably-okay.

>
>Other units may potentially ask the user some question. The place
>of those units is determined by the amount of information they need
>at the point they have to guess a reasonable default. Trying to
>grouping them topologically is possible but it is not guaranteed
>that no interleaving unit will be placed between those questions,
>since the topological order is no a full order in the mathematical
>sense.
>
>Besides, I *never* use the -d switch the first time I run a Configure
>script because I prefer have a good look at the questions asked to
>me to be able to figure out what could possibly have gone wrong later
>on. So having the questions groupped is not a matter of importance to
>me, although I understand it might be to others.
>
>Since there are some other topics rated with an higher priority in
>my TODO list, the best thing to do would be for someone with a
>high enough motivation to grab the latest dist-3.0 distribution and
>try to implement this grouping scheme.
>
>Raphael