RE: Building Octave w MXE-built dependencies (2)

[John D]

-----Original Message-----
From: Philip Nienhuis [mailto:address@hidden 
Sent: Friday, June 21, 2013 10:00 AM
To: John D
Cc: 'John W. Eaton'; 'Octave Maintainers List'
Subject: Re: Building Octave w MXE-built dependencies (2)

John D wrote:
>
>
> -----Original Message-----
> From: Philip Nienhuis [mailto:address@hidden
> Sent: Friday, June 21, 2013 9:14 AM
> To: John D
> Cc: 'John W. Eaton'; 'Octave Maintainers List'
> Subject: Re: Building Octave w MXE-built dependencies (2)
>
> John D wrote:
>>
>>
>> -----Original Message-----
>> From: Philip Nienhuis [mailto:address@hidden
>> Sent: Friday, June 21, 2013 8:49 AM
>> To: John D
>> Cc: John W. Eaton; Octave Maintainers List
>> Subject: Building Octave w MXE-built dependencies (2)
>>
>>> John D, did I read you correctly that:
>>>> Also, just for info, I created a script in tools/set_mxe_env.sh you 
>>>> can
>>> run as source tools/set_mxe_env.sh, that sets all the bin/lib/config 
>>> paths that may help.
>>>> I created it for compiling the octave_hg versions of code in mingw 
>>>> after having a working mxe-octave.
>>>> It isn't much use for anything except for native mingw builds.
>>> ... that script is meant to aid exactly that purpose?
>>>
>>> Yes the script is for that - I have successfully built octave 
>>> checked out from octave hg a few times now.
>>> All you need to do is check out the sources, source the 
>>> set_mxe_env.sh script, and then run run bootstrap, configure, make 
>>> like you normally would have to on a unix system.
>>>
>>> It will build octave, but fail at generating all the documentation, 
>>> but the ./run-octave script in the build directory will run the 
>>> latest and greatest from the octave hg repo!
>>
>> Here a fresh clone (parent: 16793:cc1657be1ee7 tip) fails while 
>> building the
>> parser:
>>
>> :
>> /bin/sh ../../octave/build-aux/ylwrap 
>> ../../octave/libinterp/parse-tree/lex.ll lex.octave_.c 
>> parse-tree/lex.cc
>> -- flex -I -I
>> gperf -t -C -D -G -L C++ -Z octave_kw_hash 
>> ../../octave/libinterp/parse-tree/octave.gperf>
>> parse-tree/oct-gperf.h-t1 /bin/sed 's,lookup\[,gperf_lookup[,'< 
>> parse-tree/oct-gperf.h-t1>  parse-tree/oct-gperf.h-t mv 
>> parse-tree/oct-gperf.h-t parse-tree/oct-gperf.h rm -f
> parse-tree/oct-gperf.h-t1 case "" in \
>>              *quote*) quote='"' ;; \
>>              *) quote="" ;; \
>>            esac; \
>>            case "" in \
>>              *dash*) decl="%define api.push-pull 
>> ${quote}both${quote}"; ;;
> \
>>              *underscore*) decl="%define api.push_pull 
>> ${quote}both${quote}"; ;; \
>>            esac; \
>>            /bin/sed "s/%PUSH_PULL_DECL%/$decl/"
>> ../../octave/libinterp/parse-tree/oct-parse.in.yy>
>> parse-tree/oct-parse.yy-t mv parse-tree/oct-parse.yy-t 
>> parse-tree/oct-parse.yy /bin/sh ../../octave/build-aux/ylwrap 
>> parse-tree/oct-parse.yy y.tab.c parse-tree/oct-parse.cc y.tab.
>> h parse-tree/oct-parse.h y.output parse-tree/oct-parse.output --   -dv
>> ../../octave/build-aux/ylwrap: line 108: -dv: command not found
>> make[2]: *** [parse-tree/oct-parse.cc] Error 1
>>
>>
>> I've experimented a bit but I couldn't spot where the offending "-dv"
>> came from.
>> The isolated "--" comes from libinterp/Makefile (L. 9053).
>>
>> Any suggestions?
>>
>> Philip
>>
>> -------------
>>
>> Not sure if it has anything to do with it, but when running each of 
>> the following, what versions are they?
>> bison --version
>> flex --version
>> gperf --version
>
> FYI, flex comes from mingw-get (after updating&  upgrading so I 
> suppose it should be up-to-date).
> bison and gperf have been built using mxe as build-bison and 
> build-gperf
>
>
> address@hidden ~/octave
> $ bison --version
> bison (GNU Bison) 2.7.12-4996
> Written by Robert Corbett and Richard Stallman.
>
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There 
> is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
> PARTICULAR PURPOSE.
>
> address@hidden ~/octave
> $ flex --version
> flex 2.5.35
>
> address@hidden ~/octave
> $ gperf --version
> GNU gperf 3.0.4
> Copyright (C) 1989-1998, 2000-2004, 2006-2009 Free Software Foundation,
Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Written by Douglas C. Schmidt and Bruno Haible.
>
> -------------
<John D:>
>
> Ok - I mentioned in a  previous email the other day about bison that 
> gets built with mxe - at least in native mingw - not sure of why it 
> doesn't work, but the fix is:
>
> Delete usr/bin/bison.exe from the mxe build Run Mingw-get install 
> msys-bison  to get the msys version of bison Bison --version should 
> the give 2.4.2 Rerun the configure and make again

Thanks for this suggestion, worth a try.

Interestingly, bison was already installed:

mingw-get.exe: *** ERROR *** package
bison-2.4.2-1-msys-1.0.13-bin.tar.lzma is already installed

... happened maybe while installing the mingw build tools during mingw
installation proper.

Made me wonder why the build from within mxe works OK, but not from
outside... I think that initially msys-bison was earlier in the PATH so mxe
used it anyway. However, running "source set_mxe_env.sh" has put it after
the mxe-built bison.
So maybe the line in tools/set_mxe_env.sh.in should read:

export PATH=$PATH:"$MXEDIR/usr/$HOST/bin:$MXEDIR/usr/bin"

??

Philip

-----

I believe the mxe distribution has already generated the files that bison
etc generates so works ok.
Perhaps the better way will be to not generate a bison that doesn't work for
the native mingw (or make it so it does work :) )
I recall reading a bug report somewhere on newer versions of bison breaking
the configure detection - I don't know if that's the issue here, and whether
that previous issue was fixed.