[GRASS5] configure.in Wants testers...

GRASS GRASS developer
21

On Tue, Nov 28, 2000 at 04:26:38PM +0700, Justin Hickey wrote:

I would have thought so but that is the current problem on my system.
The @SRCDIR@ variable is substituted with $(pwd) without executing the
pwd command. So it is now a make variable called pwd which is empty.
However, I did notice in that section of configure.in, that there are
brace brackets {} used for $top_srcdir but parenthesis () used for $pwd.
Could that be the problem? Just a wild guess.

Well here's my understanding:

foo=${bar} # Perform variable expansion on "bar", put result in foo.

foo=$(bar) # Execute "bar" in a subshell, put result in foo.

The $(cmd) syntax is supposed to be the portable equivalent of `cmd`,
only special characters $ \ and * (I think) are not treated as
"metacharacters".

This $(...) syntax is different from Makefile $(...) which apparently is
variable substitution/expansion.

Bye,
--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

22

On Tue, Nov 28, 2000 at 08:34:48AM -0800, Eric G . Miller wrote:

On Tue, Nov 28, 2000 at 04:26:38PM +0700, Justin Hickey wrote:
> I would have thought so but that is the current problem on my system.
> The @SRCDIR@ variable is substituted with $(pwd) without executing the
> pwd command. So it is now a make variable called pwd which is empty.
> However, I did notice in that section of configure.in, that there are
> brace brackets {} used for $top_srcdir but parenthesis () used for $pwd.
> Could that be the problem? Just a wild guess.

Well here's my understanding:

foo=${bar} # Perform variable expansion on "bar", put result in foo.

foo=$(bar) # Execute "bar" in a subshell, put result in foo.

The $(cmd) syntax is supposed to be the portable equivalent of `cmd`,
only special characters $ \ and * (I think) are not treated as
"metacharacters".

This $(...) syntax is different from Makefile $(...) which apparently is
variable substitution/expansion.

Eric,

thanks for this info:

GRASS:~/ggg > foo=$(pwd); echo $foo
/home/neteler/ggg
GRASS:~/ggg > foo=${pwd}; echo $foo

GRASS:~/ggg >

Another interesting hint for script programming!

BTW: Does anyone know a *good* book on script progamming containing such
"sekrets" and even more?

Regards
Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

23

Hi Eric

"Eric G . Miller" wrote:

On Tue, Nov 28, 2000 at 04:26:38PM +0700, Justin Hickey wrote:
Well here's my understanding:

foo=${bar} # Perform variable expansion on "bar", put result in foo.

foo=$(bar) # Execute "bar" in a subshell, put result in foo.

The $(cmd) syntax is supposed to be the portable equivalent of `cmd`,
only special characters $ \ and * (I think) are not treated as
"metacharacters".

This $(...) syntax is different from Makefile $(...) which apparently
is variable substitution/expansion.

Ahh, OK, I went looking into why this doesn't seem to work for SGI and
found on the man page for sh the following:

Command Substitution
The standard output from a command enclosed in parentheses preceded by a
dollar sign ( $() ) or a pair of grave accents (``) may be used as part
or all of a word; trailing newlines are removed.

Obviously it is supposed to work on SGI's, they even claim the (``)
style to be archaic. However the following script

#!/bin/sh

qwer=$(pwd)
asdf=`pwd`
echo $qwer
echo $asdf

Produces the following output

$(pwd)
/usr/people/jhickey/testDir/sh

Thus, it obviously does not work on SGI as it is supposed to. I am due
for an OS upgrade soon, so if this problem is not solved with the
upgrade, I will try to submit a bug report to SGI.

In the meantime, would it be safe to change the SRCDIR code in
configure.in to `pwd` instead of $(pwd)? Perhaps we can add a comment to
change it back to $(pwd) when SGI fixes this bug. Just an idea.

BTW, do you want me to submit the bindir change or do you want to? I
didn't change it yesterday because I didn't have time to test --bindir
and --with-bindir. I tested them today and --bindir seems to work, but
--with-bindir does not, but then I can't find --with-bindir in the
configure.in file. Please let me know what you want to do.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

24

Hi all,

On Tue, Nov 28, 2000 at 05:31:27PM -0800, Eric G . Miller wrote:

On Tue, Nov 28, 2000 at 05:51:45PM +0000, Markus Neteler wrote:
> Hi Eric,
>
> thanks for the LZW bugfix. While recomiling I found:
>
> gcc -g -O2 -I/home/neteler/ggg/src/include -c set_prior.c -o
> OBJ.i686-pc-linux-gnu/set_prior.o
> set_prior.c:55: warning: 'PRIO_PROCESS' redefined
> /usr/include/bits/resource.h:200: warning: this is the location of the
> previous definition
>
> It is:
> #define PRIO_PROCESS 0
>
> Does this matter? Is this an issue for "configure.in"?

No idea. I've seen it to, but it's been there for awhile, and nothing
that I've touched.

Does anyone have a recommendation here? Or can we ignore the warning?

Thanks

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

25

On Wed, Nov 29, 2000 at 11:17:16AM +0700, Justin Hickey wrote:

Ahh, OK, I went looking into why this doesn't seem to work for SGI and
found on the man page for sh the following:

Command Substitution
The standard output from a command enclosed in parentheses preceded by a
dollar sign ( $() ) or a pair of grave accents (``) may be used as part
or all of a word; trailing newlines are removed.

Obviously it is supposed to work on SGI's, they even claim the (``)
style to be archaic. However the following script

#!/bin/sh

qwer=$(pwd)
asdf=`pwd`
echo $qwer
echo $asdf

Produces the following output

$(pwd)
/usr/people/jhickey/testDir/sh

Thus, it obviously does not work on SGI as it is supposed to. I am due
for an OS upgrade soon, so if this problem is not solved with the
upgrade, I will try to submit a bug report to SGI.

In the meantime, would it be safe to change the SRCDIR code in
configure.in to `pwd` instead of $(pwd)? Perhaps we can add a comment to
change it back to $(pwd) when SGI fixes this bug. Just an idea.

I made some changes like this last night. Not sure if I got them all,
but I think so. I was using the $(...) syntax for grep the
TK_VERSION/TCL_VERSION and for "pwd", both are using `...` now.

BTW, do you want me to submit the bindir change or do you want to? I
didn't change it yesterday because I didn't have time to test --bindir
and --with-bindir. I tested them today and --bindir seems to work, but
--with-bindir does not, but then I can't find --with-bindir in the
configure.in file. Please let me know what you want to do.

--with-bindir was removed (it will silently be ignored by configure).

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

26

Hi Eric,

I can imagine that you are somewhat tired of this configure
problems...

I think I know the problem:
- the current "configure" runs o.k. (after moving the prefix expansion
   upwards)
- the autoconf rules don't accept your GISBASE part properly as
   it must come *below* the prefix expansion. But in any case
   the expansion cames later. So it must obvisously coded in a different
   way.

If you run "autoconf", check configure:
- Add VERSION and GISBASE is at line 4292 ff.
- the prefix expansion is at line 4351
   (test "x$prefix" = xNONE && prefix=$ac_default_prefix)
- if you reverse the order, it runs well. However, autoconf
   doesn't allow it as all the stuff below line 4295 is generated
   automatically.
I have no clue to fix that in configure.in. Perhaps the
VERSION, NAME_VER and GISBASE expansion is just not possible.

At time we have a working configure in CVS and a broken configure.in.
This is the last change to be done for beta9.

I propose to revert to old method and leave it for 5.0stable.

Regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

27

Eric, (Grass)

Using the line

gcc -o gltest gltest.c -lGLU -lGL -L/usr/X11R6.4/lib -lX11 -lSM -lICE -lXext

will compile the test source code that you have in the
configure script under Cygwin to use the GL libes.

John Huddleston

----- Original Message -----
From: "Eric G . Miller" <egm2@jps.net>
To: "GRASS5-dev" <grass5@geog.uni-hannover.de>
Sent: Thursday, November 23, 2000 10:32 PM
Subject: [GRASS5] configure.in Wants testers...

Okay,

I think I've implemented all of the checks in the hacked configure
script in configure.in. So, now I need others to test it and give me
problem reports. I haven't added anything, like searching for libjpeg,
yet. I want to get the input script at least to where the hacked
configure script is before I start adding things. Probably there will
be search paths for things that I didn't think of. Anyway, make a
backup of the configure script and delete your config.cache before
running autoconf. Also, note that there doesn't seem to be a good way
to have the --bindir default to /usr/local/bin. The macro
AC_DEFAULT_BINDIR() was not recognized by my autoconf and the variable
$bindir is always set to something (defaulting to ${exec_prefix}/bin,
where $exec_prefix defaults to ${prefix} which is set to
/usr/local/grass5 by default. Confused?). So, if you want
/usr/local/bin for $bindir, you need to specify it. Also, see
./configure --help for some of the options (they need testing too).

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

28

On Fri, Dec 29, 2000 at 07:35:49AM -0700, John Huddleston wrote:

Eric, (Grass)

Using the line

gcc -o gltest gltest.c -lGLU -lGL -L/usr/X11R6.4/lib -lX11 -lSM -lICE -lXext

will compile the test source code that you have in the
configure script under Cygwin to use the GL libes.

Does it really need all those X libraries? They are not set anywhere in
src/CMD/head/head.in (only -lX11 and -lXt). I don't know why the X
libes are in /usr/X11R6.4/lib instead of /usr/X11R6/lib. But this is
what breaks the AC_PATH_XTRA macro for setting X_LIBS. By the way, the
AC_PATH_XTRA macro will recognize --x-includes=DIR, --x-libraries=DIR,
and --without-x.

Anyway, if -lSM, -lICE, and -lXext are really needed, then we'll have to
modify src/CMD/head/head.in and the Gmakefiles for NVIZ and r3.showdspf.

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

29

Eric, (Grass)

I had to add the -lGLw to the line. There is no libGLwM in Cygwin.
The testing for this in the configure would not work until I set a LIBS
variable as follows in my configure-grass.sh script

LIBS="-lGLw -lGLU -lGL -L/usr/X11R6.4/lib -lXm -lXt -lX11 -lSM -lICE -lXext"
export LIBS
rm -i config.cache
./configure --prefix=/usr/local --exec-prefix=/usr/local --with-x-libs=/usr/X11R6.4/lib --with-x-includes=/usr/X11R6.4/include --wit
h-x

The src/CMD/head/head.i686-pc-cygwin file is not good when you
do it this way. You have to hand edit that file and then the make
works. Attached is a ZIP file containing this file for anyone's
reference.

It would be nice for the configure to create a clean head file.

John Huddleston

----- Original Message -----
From: "Eric G . Miller" <egm2@jps.net>
To: "grass5" <grass5@geog.uni-hannover.de>
Sent: Friday, December 29, 2000 11:35 AM
Subject: Re: [GRASS5] configure.in Wants testers...gl for cygwin

On Fri, Dec 29, 2000 at 07:35:49AM -0700, John Huddleston wrote:
> Eric, (Grass)
>
> Using the line
>
> gcc -o gltest gltest.c -lGLU -lGL -L/usr/X11R6.4/lib -lX11 -lSM -lICE -lXext
>
> will compile the test source code that you have in the
> configure script under Cygwin to use the GL libes.

Does it really need all those X libraries? They are not set anywhere in
src/CMD/head/head.in (only -lX11 and -lXt). I don't know why the X
libes are in /usr/X11R6.4/lib instead of /usr/X11R6/lib. But this is
what breaks the AC_PATH_XTRA macro for setting X_LIBS. By the way, the
AC_PATH_XTRA macro will recognize --x-includes=DIR, --x-libraries=DIR,
and --without-x.

Anyway, if -lSM, -lICE, and -lXext are really needed, then we'll have to
modify src/CMD/head/head.in and the Gmakefiles for NVIZ and r3.showdspf.

--
Eric G. Miller <egm2@jps.net>

(attachments)

hcygwin.zip (1.74 KB)

30

On Sat, Dec 30, 2000 at 07:08:10AM -0700, John Huddleston wrote:

Eric, (Grass)

I had to add the -lGLw to the line. There is no libGLwM in Cygwin.
The testing for this in the configure would not work until I set a LIBS
variable as follows in my configure-grass.sh script

LIBS="-lGLw -lGLU -lGL -L/usr/X11R6.4/lib -lXm -lXt -lX11 -lSM -lICE -lXext"
export LIBS
rm -i config.cache
./configure --prefix=/usr/local --exec-prefix=/usr/local --with-x-libs=/usr/X11R6.4/lib --with-x-includes=/usr/X11R6.4/include --wit
h-x

The src/CMD/head/head.i686-pc-cygwin file is not good when you
do it this way. You have to hand edit that file and then the make
works. Attached is a ZIP file containing this file for anyone's
reference.

It would be nice for the configure to create a clean head file.

Okay, here is what I see for CygWin compatibility:

(1) Need to resolve this yacc vs. bison -y

(2) Need to include $X_PRE_LIBS, $X_LIBS, -lXext ?, and -lX11 for Tcl/Tk
    and OpenGL tests. The OpenGL libes shouldn't be set in the
    XLIBPATH, but down in the OPENGL... area. Using --x-includes= and
    --x-libraries= should take care of the funny directory naming under
    CygWin; no need for an extra --with-x-<whatever> as this is already
    handled by the AC_XTRA macro.

(3) IPC is in a separate library under CygWin (-lcygipc). Will this
    always be the case? or is it because this functionality is not quite
    finished? (It's in libc for most systems.)

(4) r3.showdspf can't be compiled due to lack of Motif/Lesstif? and
    no libGLwM? (this may not be true if libGLw is already compiled with
    Motif/Lesstif support ???).

(5) libtk80.a and libtcl80.a should already be handled with change made
    yesterday.

Is there anything else I missed?

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

31

Eric, (Grass, Mike, and Andreas)

----- Original Message -----
From: "Eric G . Miller" <egm2@jps.net>
To: "grass5" <grass5@geog.uni-hannover.de>
Sent: Saturday, December 30, 2000 12:38 PM
Subject: Re: [GRASS5] configure.in Wants testers...gl for cygwin

<snip>

Okay, here is what I see for CygWin compatibility:

(1) Need to resolve this yacc vs. bison -y

It is simple to make a symbolic link in /bin as well. However,
we could test for both.

(2) Need to include $X_PRE_LIBS, $X_LIBS, -lXext ?, and -lX11 for Tcl/Tk
    and OpenGL tests. The OpenGL libes shouldn't be set in the
    XLIBPATH, but down in the OPENGL... area. Using --x-includes= and
    --x-libraries= should take care of the funny directory naming under
    CygWin; no need for an extra --with-x-<whatever> as this is already
    handled by the AC_XTRA macro.

As you wish.

(3) IPC is in a separate library under CygWin (-lcygipc). Will this
    always be the case? or is it because this functionality is not quite
    finished? (It's in libc for most systems.)

I think Andreas and Mike are looking at this as well. We depend
to a great amount on the redhat/cygwin developers for updates to
the cygipc code. It has always been a separate library from
the main Cygwin distribution. The http://cygutils.netpedia.net/V1.1/cygipc/index.html
does not come from the redhat distribution areas nor from the
ftp mirror sites (contrib, latest and xfree). I do not know the
future of it.

(4) r3.showdspf can't be compiled due to lack of Motif/Lesstif? and
    no libGLwM? (this may not be true if libGLw is already compiled with
    Motif/Lesstif support ???).

There is Lesstif. The routines in libGLmW have been included in the
three other GL libes. I'll tackle this compile for us. Where is it?
What directory?

(5) libtk80.a and libtcl80.a should already be handled with change made
    yesterday.

OK

Is there anything else I missed?

Andreas? Mike? any comments?

John Huddleston

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'