[GRASS-dev] error ./configuring trunk

Hi,

with latest svn when I try to ./configure trunk I get a whole pile of
sed usage errors:

checking whether to use Python... yes
checking for python-config... /usr/bin/python2.5-config
checking for Python.h... yes
sed: invalid option -- E
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...

  -n, --quiet, --silent
                 suppress automatic printing of pattern space
  -e script, --expression=script
                 add the script to the commands to be executed
  -f script-file, --file=script-file
                 add the contents of script-file to the commands to be executed
  -i[SUFFIX], --in-place[=SUFFIX]
                 edit files in place (makes backup if extension supplied)
  -l N, --line-length=N
                 specify the desired line-wrap length for the `l' command
  --posix
                 disable all GNU extensions.
  -r, --regexp-extended
                 use extended regular expressions in the script.
  -s, --separate
                 consider files as separate rather than as a single continuous
                 long stream.
  -u, --unbuffered
                 load minimal amounts of data from the input files and flush
                 the output buffers more often
      --help display this help and exit
      --version output version information and exit

If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret. All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.

E-mail bug reports to: bonzini@gnu.org .
Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.
sed: invalid option -- E
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...

  -n, --quiet, --silent
                 suppress automatic printing of pattern space
  -e script, --expression=script
                 add the script to the commands to be executed
  -f script-file, --file=script-file
                 add the contents of script-file to the commands to be executed
  -i[SUFFIX], --in-place[=SUFFIX]
                 edit files in place (makes backup if extension supplied)
  -l N, --line-length=N
                 specify the desired line-wrap length for the `l' command
  --posix
[...]
specified, then the standard input is read.

E-mail bug reports to: bonzini@gnu.org .
Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.
creating ./config.status
creating include/Make/Platform.make
creating include/version.h
creating swig/perl/Makefile.PL
creating swig/perl2/make.pl
creating grass.pc
creating include/config.h
Copying config.status to config.status.x86_64-unknown-linux-gnu

GRASS is now configured for: x86_64-unknown-linux-gnu
[...]
  Python support: yes
[...]

It seems to build ok except for wxVdigit, wxNviz, and xganim.

?,
Hamish

Oops, I think it's the OSX arch options I added this weekend - they use the -E sed flag that's in BSD sed, but maybe not in GNU sed? I wasn't sure if I should (or how) to only check those parts on OSX (it does NOT have anything to do with the OSX app option). Or is there an equivalent -E option that works in GNU and BSD?

Is it OK to check the $system var in configure.in, when it's something that's created by an autocof macro? Or is there an AC macro that can do something based on the system?

On Sep 8, 2009, at 3:49 PM, Hamish wrote:

Hi,

with latest svn when I try to ./configure trunk I get a whole pile of
sed usage errors:

checking whether to use Python... yes
checking for python-config... /usr/bin/python2.5-config
checking for Python.h... yes
sed: invalid option -- E
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day."

<Ha, ha> "And it might give 'em all stomach ulcers."

- Tarzan, on war

I removed the BSD option and reworked the sed commands. Sorry for the mess.

On Sep 8, 2009, at 4:03 PM, William Kyngesburye wrote:

Oops, I think it's the OSX arch options I added this weekend - they use the -E sed flag that's in BSD sed, but maybe not in GNU sed? I wasn't sure if I should (or how) to only check those parts on OSX (it does NOT have anything to do with the OSX app option). Or is there an equivalent -E option that works in GNU and BSD?

Is it OK to check the $system var in configure.in, when it's something that's created by an autocof macro? Or is there an AC macro that can do something based on the system?

On Sep 8, 2009, at 3:49 PM, Hamish wrote:

Hi,

with latest svn when I try to ./configure trunk I get a whole pile of
sed usage errors:

checking whether to use Python... yes
checking for python-config... /usr/bin/python2.5-config
checking for Python.h... yes
sed: invalid option -- E
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

William Kyngesburye wrote:

Oops, I think it's the OSX arch options I added this weekend - they
use the -E sed flag that's in BSD sed, but maybe not in GNU sed? I
wasn't sure if I should (or how) to only check those parts on OSX (it
does NOT have anything to do with the OSX app option). Or is there an
equivalent -E option that works in GNU and BSD?

Is it OK to check the $system var in configure.in, when it's something
that's created by an autocof macro? Or is there an AC macro that can
do something based on the system?

You should probably use AC_CANONICAL_BUILD and $build, as that
specifies the platform on which the package is being built.

It doesn't make much difference right now, as cross-compilation is
broken, but that might get fixed in the future.

--
Glynn Clements <glynn@gclements.plus.com>