Hi,
Looks good. With a fresh checkout I now get :
Determining whether GNU m4 is
installed.................................no.
And in the m4 makefile
# some constants
M4_EVAL_COMPILER_SO = ../../runtime/parrot/dynext/m4_eval_compiler.so
default: all
all: build
Certainly easier to go this route. I wonder how many non gnu m4
will hang when given m4 --version? Hopefully not too many :)
I have hacked around with the languages/m4 to run the tests against
gm4(which happens
to be installed on the system) and all the tests pass.
The only very very minor problem is the m4 makefile does not work with
free bsd make but I imagine
anyone with gnu m4 installed will have gnu make so I guess this isn't
a problem.
Replacing the pattern rule
%.pbc: %.pir
$(PARROT) -o $@ $<
%.pbc: %.imc
$(PARROT) -o $@ $<
with a specific rule for src/m4.pbc fixes this and may be worth doing
as long as you
do not expect to add any/many other pir files that need compilation
Peter
-----Original Message-----
From: Bernhard Schmalhofer via RT <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: 2 Jun 2005 17:45:06 -0000
Subject: [perl #36087] FreeBSD - configure hangs when running m4
Hi Peter,
> When configure runs config/auto/m4.pl to detect if the system
> m4 is gnu it hangs. Running "m4 --version" does not display
> the version number for freebsd m4. m4 starts up and sits their
> waiting for input from STDIN.
>
> Parrot::Configure::Step::capture_output ( used by m4.pl )
> should probably be modified to timeout commands after 60 seconds
> and/or
> it should be possible to specify the override the name of the m4
> binary in the platform/local hints file.
I think that it is save to skip this test altogether on FreeBSD.
A hopefully appropriate patch is in SVN revision 8255 of Parrot.
The m4 check is explicitly for GNU m4. When there is a GNU m4, then
cd languages/m4
make test
runs the test suite twice, for Parrot m4 and for GNU m4.
Could you check whether 'has_gnu_m4' is really set to 0 on FreeBSD?
CU, Bernhard
--
/* [EMAIL PROTECTED] */
