ports/51283: expat2 port fails to configure

[Anton Berezin]

The following reply was made to PR ports/51283; it has been noted by GNATS.

From: Anton Berezin <tobez at tobez.org>
To: Charles Swiger <cswiger at mac.com>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: ports/51283: expat2 port fails to configure
Date: Tue, 22 Apr 2003 19:16:33 +0200

 On Tue, Apr 22, 2003 at 09:40:16AM -0700, Charles Swiger wrote:
 
 >  Good call, Anton: I don't define $UNAME in /etc/make, but I do have
 >  it set in my shell startup scripts-- unsetting it is a valid
 >  workaround to the bug.
 >  
 >  That being said, I've been setting $UNAME to `uname -s` for about
 >  fifteen years for reasons which continue to be valid to me.
 >  ./configure should unset $UNAME if it can't deal with that being set
 >  to a reasonable value, or at least issue a warning.
 
 I am not quite sure it is feasible.  Configure script of a particular
 port has very little to do with it.  The actual culprit is the line
 
 UNAME?= /usr/bin/uname
 
 at /usr/ports/Mk/bsd.port.mk.  ${UNAME} is being used by the ports
 collection infrastructure to determine several important variables,
 among them, ARCH and OSREL.  Both of those are used by the
 textproc/expat2 port, as well as by many other ports.  In particular,
 expat2 uses them to construct certain parameters then passed to the
 configure script.
 
 The majority (hopefully, all) of the binaries used by the ports
 collection has corresponding make variables, for example LS, ID, FIND,
 and so on.  I am not sure that changing this practice to adjust to
 habits of a single FreeBSD user is a good idea.
 
 That said, there are several possible solutions for you.
 
 One is to actually *define* a UNAME make variable to be /usr/bin/uname
 in your /etc/make.conf.  Due to the way make(1) operates, it will ignore
 your shell UNAME variable in this case.  In this way you will still have
 UNAME to be whatever it is you like it to be in the SHELL, but not
 inside makefiles.
 
 Another possibility, which I do not personally like, is to modify
 bsd.port.mk to use, for instance, UNAME_CMD instead of UNAME.
 
 Please tell me whether the first solution is good enough for you, I'll
 close this PR is this case.  Otherwise, it should be assigned to
 portmgr, and though I cannot speak for them, I am pretty sure that it
 will be closed after a brief period without actually modifying
 bsd.port.mk.
 
 Cheers,
 +Anton.
 -- 
 Perl is strongly typed, it just has very few types. -- Dan Sugalski