Mailing List Archive

Excerpts from the mail message of Tom Christiansen:
)
) i see these at every place i go. maybe -d should be the default?
[...]
) From: dks@spies.com (dk smith)
) I think the biggest improvement that could be made to the PERL distribution
) is the incorporation and use of the Autoconfig utilitiy which GNU uses.

"Improved" from an earlier message of mine to the dist-3 users' list:

How about a perl-specific solution. Add a script, autoconf,
and put _very close to the top_ of README "You might just try
./autoconf first (it works well in most cases), and run
./Configure only if you want or have to". Here is autoconf
version 0.2:

if [ 1 != $# ]; then
echo "Usage: $0 cc_cmd"
echo 'Where "cc_cmd" is the C compiler you wish to use:'
echo 'Put "." and Configure will pick a C compiler for you.'
echo 'Put "gcc" if you are using the GNU C compiler.'
# Several of the hint files need to know up front
# if you are using gcc.
echo 'Some systems offer other choices like "acc" or "xcl".'
exit 1
fi
case "$1" in
.) cc=;;
*) cc="-Dcc=$1";;
esac
if [ -f config.sh ]; then
if [ -f config.sh.auto ]; then
echo "Removing old config.sh"
rm config.sh
else
echo "Moving old config.sh to config.sh.auto"
mv config.sh config.sh.auto
fi
fi
echo "Running: ./Configure -ds $cc"
./Configure -ds $cc
echo "(You can change the paths where Perl will be installed"
echo " by editing config.sh now.)"

--
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)

> >In comp.lang.perl.misc, dks@spies.com (dk smith) writes:

: Though, after trying to build it I wish it's build configuration
: script and subsequent make performed as consistently and successfully
: as many of the GNU tools.

When I started to add Configure support to perl5 (back in March 1994)
I actually did think about autoconf a bit. At that time, I tried a
wide variety of GNU tools on my system. Not a single one compiled,
built, and installed correctly out of the box with the system
compiler. I decided to stick with metaconfig/COnfigure.

My two main complaints with GNU configure are:
1. If it makes a mistake, it can be *very* hard to fix it,
especially if that mistake affects subsequent tests. You probably
have to edit the configure shell script.
2. If there are several possible answers, there may be no way to
choose which one to use. For example, suppose your system allows
compilation in either a POSIX environment or a "native" environment.
Which is better may depend on the particular application and your
requirements. If autoconf decides you want POSIX, you're stuck.

These and other problems are fixed by making Configure
interactive by default. To some extent, GNU configure allows
customization, e.g.
CC='cc -foo -bar' ./configure --with-option-1
but this is an incomplete and inconsistent mechanism. There's not a
--with- option for everything you might need to change.

: The configure script distributed with
: 5.0001 is a real pain on Solaris 2.4 when using gcc 2.7.0 and GNU
: make. Just my 2 cents.

sh Configure -Dcc=gcc -ds
or
CC=gcc ./configure
should work just fine on Solaris 2.4. (If you're willing to run GNU
configure, it means you're willing to accept all the defaults
anyway, since GNU configure doesn't give you the opportunity to
accept anything but the defaults.)

If the configuration script gets all the right answers, who cares if
it was generated by autoconf or metaconfig? But if it gets the
wrong answers, I appreciate having an easy way to correct it.

Certainly some prompts in Configure could be improved or clarified,
and others could be eliminated. The README could probably be
improved to give the user more confidence in accepting the default
values. Overall, though, it seems to work.

Just my 2 cents.

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

On Wed, 6 Sep 1995, Tom Christiansen wrote:

> i see these at every place i go. maybe -d should be the default?

Since 5.001m now includes a 'configure' script that emulates GNU
configure (sort-of), this may be more of a documentation issue than
anything else. Certainly I could mention 'configure' and also try
to instill more confidence in Configure's defaults, at least for
popular systems like SunOS 4.1.3.

I worry that such advice won't be read since README is already rather
long. Does anyone think it would help if the installation
instructions were broken out of README and put into a separate
INSTALL file? I'd probably have a 'try the defaults' section and
then a 'what to do if it doesn't work' section.

I can't promise anything soon since my system is *still* broken
(don't ask) and my top priority around here is still fixing it.

Andy Dougherty doughera@lafcol.lafayette.edu

Excerpts from the mail message of Andy Dougherty:
) Since 5.001m now includes a 'configure' script that emulates GNU
) configure (sort-of), this may be more of a documentation issue than
) anything else. Certainly I could mention 'configure' and also try
) to instill more confidence in Configure's defaults, at least for
) popular systems like SunOS 4.1.3.

[.Ah. I missed that (silly me! I saw configure and thought it was
Configure and so didn't notice that Configure was also there). I
was going to suggest a "configure" script but thought the conflict
on case insensitive systems might be a problem.]

Anyway, I propose some minor changes...

) I worry that such advice won't be read since README is already rather
) long. Does anyone think it would help if the installation
) instructions were broken out of README and put into a separate
) INSTALL file? I'd probably have a 'try the defaults' section and
) then a 'what to do if it doesn't work' section.

Yes. That is why I previously emphasized "very near the top of
README". The pointer to the INSTALL file should appear "very near
the top of README". I've also wrote a README.svr4 that starts
right up with the simple way to build on SVR4 (since it is a bit
unique) and then goes into more details farther down (you can it
at http://www.metronet.com/~tye/perlsvr4.html). So a pointer to
README.svr should probably appear near the top of INSTALL.

I also like the way my "autoconf" script _forced_ you to decide if
you wanted to use gcc before you ran it (not specifying a compiler
was considered an error). I intentionally didn't show an example
of how to "let Configure pick the compiler" except in the usage
message for "autoconf" to prevent people from latching onto that
example and missing that they need to specify gcc else some hints
files won't work right.

I also think "./Configure -ds" should be the default instead of
"-des" so that you can suggest that they edit config.sh to change
any paths that they don't like. Changing paths this way should be
fairly simple (you can tell which part of config.sh to change
based on the path values without having to know what the variable
names mean -- and the variable names for path values are pretty
easy to understand as well) and not very error prone as the path
options don't cascade and affect other options much.

Along with this, ending "configure" with some very brief
instructions on how to change paths this way would be nice.

Finally, ./configure should move/remove config.sh in case, as
is often the case, they try to run ./Configure and answer some
questions "incorrectly" and don't get it to work and so _then_
decide to try all the defaults. See my other message for my
latest preferred method to do this.

If anyone would rather have the above re-expressed as a patch,
I'll try to throw one together.
--
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)

Andy Dougherty writes:
>
> On Wed, 6 Sep 1995, Tom Christiansen wrote:
>
> > i see these at every place i go. maybe -d should be the default?
>
> Since 5.001m now includes a 'configure' script that emulates GNU
> configure (sort-of), this may be more of a documentation issue than
> anything else. Certainly I could mention 'configure' and also try
> to instill more confidence in Configure's defaults, at least for
> popular systems like SunOS 4.1.3.
>
> I worry that such advice won't be read since README is already rather
> long. Does anyone think it would help if the installation
> instructions were broken out of README and put into a separate
> INSTALL file? I'd probably have a 'try the defaults' section and
> then a 'what to do if it doesn't work' section.

Let me remind one other question. On case-forgiving file systems
configure/Configure dilemma ends in a funny way: Only one name
survives, and it contains the _wrong_ file ;-) !

The reason is that the first file in the tar is extracted as is, the
second one overwrites the first, but this overwriting preserves the
file name (since the system is not case-unsensitive, but
case-forgiving).

The solution may be to have copies of these files in a subdirectory
with different names, or maybe you can propose something else. It is
not that you cannot extract the filses now, but for this you need to
specify the complete names to tar, not very pleasant.

Ilya

> Andy Dougherty writes:
> > Since 5.001m now includes a 'configure' script that emulates GNU
> > configure (sort-of), this may be more of a documentation issue than
> > anything else. Certainly I could mention 'configure' and also try
> > to instill more confidence in Configure's defaults, at least for
> > popular systems like SunOS 4.1.3.

I never discovered that there was a ./configure script. I would suggest two
changes to ./configure:

make it executable in the distribution package
make './configure --help' stop after printing the help message

--Gisle

On Wed, 6 Sep 1995, Tom Christiansen wrote:

> i see these at every place i go. maybe -d should be the default?

My personal opinion is that a good deal of this is founded in people not
liking the look of metaconfig, compared to autoconf, (I do agree with
this, BTW. The output of Autoconf's config scripts looks nice and
streamlined, and it in general seems faster. But then Perl's Configure is
probably the most massive configuration script currently in use.) and just
deciding that they aren't going to like Configure, no matter what comes.
And then the questions, defaults not withstanding, give people an
oppurtunity to fiddle about that is probably more trouble then it's worth.

What I'd eventually like to see is a complete "autoconf" mode for
Configure that cuts way down on the output, cuts out all non-critical
questions, accepts the defaults, etc.

Oh, and perhaps presenting a tsort-ed list of -D overrides to the user
might be helpful for people trying to work out configuration problems.
-Dcc would probably come at the top of the list, of course.

> ------- Forwarded Message
> [...]
> >:Though, after trying to build it I wish it's build configuration script
> >:and subsequent make performed as consistently and successfully as many of
> >:the GNU tools. The configure script distributed with 5.0001 is a real pain
> >:on Solaris 2.4 when using gcc 2.7.0 and GNU make. Just my 2 cents.
>
> >Did you use 'Configure -de' or not?
> >Did you learn something that we can use so next time it's easier?
> >Did you submit a bug to perlbug@perl.com?
>
> Nothing I saw would come across to me as a bug. It was simply a pain.

This is the problem. _What_ was a pain? Or has Raphael managed to embed
phsycoactive pain generators in shell scripts? :-)

> Things did not work for me. (And this is just after I built several GNU
> tool distributions without a hitch (at least 8-10 GNU packages).

Same deal. "Things did not work for me." Hardly helpful. But the
parenthetic comments makes my point. Autoconf simply _feels_ smoother.

> I think the biggest improvement that could be made to the PERL distribution
> is the incorporation and use of the Autoconfig utilitiy which GNU uses.

And we all know how realistic this one is. Part of the problem here is
simply that PERL probably does more configuration then any other GNU
program. And that's exacerbated by dynamic loading.

TCL, a poor but obvious comparison point does practicaly no
configuration. I'm not sure about Python.

> dk
>
> - --
> dks@spies.com | Performance is life, entertainment is death.
>
>
>
> ------- End of Forwarded Message

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

> From: Ilya Zakharevich <ilya@math.ohio-state.edu>
>
> Let me remind one other question. On case-forgiving file systems
> configure/Configure dilemma ends in a funny way: Only one name
> survives, and it contains the _wrong_ file ;-) !
>
> The reason is that the first file in the tar is extracted as is, the
> second one overwrites the first, but this overwriting preserves the
> file name (since the system is not case-unsensitive, but
> case-forgiving).

Let Configure and configure be the same file, and start it with

case "/$0" in */configure)
<<GNU configure startup>>
;;
esac


Hallvard

On Thu, 7 Sep 1995, Ilya Zakharevich wrote:

> Let me remind one other question. On case-forgiving file systems
> configure/Configure dilemma ends in a funny way: Only one name
> survives, and it contains the _wrong_ file ;-) !

Let me second this. I've done a bit of work on Ilya's OS/2 port (good
work, by the way) and this is an utter pain. Especially considering that
some OS/2 tar's try to be "helpful" and won't treat command line options
as case sensitive without an override. Pulling "Configure" out of the tar,
as opposed to "configure" is a complete pain. On the compilation end, you
have Makefile/makefile, although Ilya worked around that one.

> The reason is that the first file in the tar is extracted as is, the
> second one overwrites the first, but this overwriting preserves the
> file name (since the system is not case-unsensitive, but
> case-forgiving).
>
> The solution may be to have copies of these files in a subdirectory
> with different names, or maybe you can propose something else. It is
> not that you cannot extract the filses now, but for this you need to
> specify the complete names to tar, not very pleasant.

The only real solution is to not have file that only differ by case. But
with the current configure/Configure, that's a little hard to do.

> Ilya

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

> Add a script, autoconf, and put _very close to the top_ of README "You
> might just try ./autoconf first (it works well in most cases), and run
> ./Configure only if you want or have to".

Quoting Gisle Aas:
:> Andy Dougherty writes:
:> > Since 5.001m now includes a 'configure' script that emulates GNU
:> > configure (sort-of), this may be more of a documentation issue than
:> > anything else. Certainly I could mention 'configure' and also try
:> > to instill more confidence in Configure's defaults, at least for
:> > popular systems like SunOS 4.1.3.
:
:I never discovered that there was a ./configure script. I would suggest two
:changes to ./configure:
:
: make it executable in the distribution package
: make './configure --help' stop after printing the help message
:
:--Gisle

Better yet, take the configure from the newest dist-3.0 which offers
more GNU-like options. You can get it my using 'metaconfig -G'.

Anyway, I've included a copy...

Raphael

#! /bin/sh
# This is a shell archive. Remove anything before this line, then feed it
# into a shell via "sh file" or similar. To overwrite existing files,
# type "sh file -c".
# The tool that generated this appeared in the comp.sources.unix newsgroup;
# send mail to comp-sources-unix@uunet.uu.net if you want that tool.
# Contents: configure
# Wrapped by ram@memphis on Thu Sep 7 14:12:13 1995
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
echo If this archive is complete, you will see the following message:
echo ' "shar: End of archive."'
if test -f 'configure' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'configure'\"
else
echo shar: Extracting \"'configure'\" \(1991 characters\)
sed "s/^X//" >'configure' <<'END_OF_FILE'
X#! /bin/sh
X#
X# $Id: configure,v 3.0.1.1 1995/07/25 14:16:21 ram Exp $
X#
X# GNU configure-like front end to metaconfig's Configure.
X#
X# Written by Andy Dougherty <doughera@lafcol.lafayette.edu>
X# and Matthew Green <mrg@mame.mu.oz.au>.
X#
X# Reformatted and modified for inclusion in the dist-3.0 package by
X# Raphael Manfredi <ram@hptnos02.grenoble.hp.com>.
X#
X# This script belongs to the public domain and may be freely redistributed.
X#
X# The remaining of this leading shell comment may be removed if you
X# include this script in your own package.
X#
X# $Log: configure,v $
X# Revision 3.0.1.1 1995/07/25 14:16:21 ram
X# patch56: created
X#
X
X(exit $?0) || exec sh $0 $argv:q
Xopts=''
Xverbose=''
Xcreate='-e'
Xwhile test $# -gt 0; do
X case $1 in
X --help)
X cat <<EOM
XUsage: configure [options]
XThis is GNU configure-like front end for a metaconfig-generated Configure.
XIt emulates the following GNU configure options (must be fully spelled out):
X --help
X --no-create
X --prefix=PREFIX
X --quiet
X --silent
X --verbose
X --version
X
XAnd it honours these environment variables: CC, CFLAGS and DEFS.
XEOM
X exit 0
X ;;
X --no-create)
X create='-E'
X shift
X ;;
X --prefix=*)
X arg=`echo $1 | sed 's/--prefix=/-Dprefix=/'`
X opts="$opts $arg"
X shift
X ;;
X --quiet|--silent)
X exec >/dev/null 2>&1
X shift
X ;;
X --verbose)
X verbose=true
X shift
X ;;
X --version)
X copt="$copt -V"
X shift
X ;;
X --*)
X opt=`echo $1 | sed 's/=.*//'`
X echo "This GNU configure front end does not understand $opt"
X exit 1
X ;;
X *)
X opts="$opts $1"
X shift
X ;;
X esac
Xdone
X
Xcase "$CC" in
X'') ;;
X*) opts="$opts -Dcc='$CC'";;
Xesac
X
X# Join DEFS and CFLAGS together.
Xccflags=''
Xcase "$DEFS" in
X'') ;;
X*) ccflags=$DEFS;;
Xesac
Xcase "$CFLAGS" in
X'') ;;
X*) ccflags="$ccflags $CFLAGS";;
Xesac
Xcase "$ccflags" in
X'') ;;
X*) opts="$opts -Dccflags='$ccflags'";;
Xesac
X
X# Don't use -s if they want verbose mode
Xcase "$verbose" in
X'') copt="$copt -ds";;
X*) copt="$copt -d";;
Xesac
X
Xset X ./Configure $copt $create $opts
Xshift
Xecho "$@"
Xexec "$@"
END_OF_FILE
if test 1991 -ne `wc -c <'configure'`; then
echo shar: \"'configure'\" unpacked with wrong size!
fi
# end of 'configure'
fi
echo shar: End of archive.
exit 0

I never discovered that there was a ./configure script.

that's because it's new since 5.001, i guess.

.mrg.