octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #34725] Something regarding Lex causes build f


From: Edd Barrett
Subject: [Octave-bug-tracker] [bug #34725] Something regarding Lex causes build failure on OpenBSD
Date: Wed, 02 Nov 2011 13:43:44 +0000
User-agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1

Follow-up Comment #2, bug #34725 (project octave):

Hi John,

Thanks for the prompt reply.

I was unaware that flex was an optional dependency and I have no need to
modify octave's grammar. Given that I have not changed or removed lex.cc or
lex.ll as distributed with the octave-3.4.3 tarball, this should work, right?

Put differently, the build error I have posted was generated from a freshly
extracted tarball with no changes to any file related to the lexer (i have
patched src/sighandlers.cc, which i believe to be unrelated).

Looking at the error message, this is builtins.cc complaining and not lex.cc.
builtins.cc is autogenerated during the build (was this supposed to be
supplied pre-generated too?).

If I run "make builtins.cc" manually and inspect the resulting builtins.cc, I
noticed the file contains lex token definitions (This is what I mean by, can
c++ compile lex tokens - I think the answer is no and something is fishy about
this):


...
static void gripe_matlab_incompatible_operator (const std::string& op);
static void display_token (int tok);
static void lexer_debug (const char *pattern, const char *text);

%}

D       [0-9]
S       [ t]
NL      ((n)|(r)|(rn))
SNL     ({S}|{NL})
EL      (...)
BS      (\)
CONT    ({EL}|{BS})
Im      [iIjJ]
CCHAR   [#%]
COMMENT ({CCHAR}.*{NL})
SNLCMT  ({SNL}|{COMMENT})
NOT     ((~)|(!))
POW     ((**)|(^))
EPOW    (.{POW})
IDENT   ([_$a-zA-Z][_$a-zA-Z0-9]*)
EXPON   ([DdEe][+-]?{D}+)
NUMBER  (({D}+.?{D}*{EXPON}?)|(.{D}+{EXPON}?)|(0[xX][0-9a-fA-F]+))
%%

%{
// Make script and function files start with a bogus token. This makes
// the parser go down a special path.
%}

<SCRIPT_FILE_BEGIN>. {
    LEXER_DEBUG ("<SCRIPT_FILE_BEGIN>.");

    BEGIN (INITIAL);
    xunput (yytext[0], yytext);
...


I see this with both flex 2.5.35 and 2.5.4 (assuming that adjusting LEX in
src/Makefile will make a difference).

The build for this step looks like this:
% gmake builtins.cc
./DLD-FUNCTIONS/config-module.sh ..
../src/DLD-FUNCTIONS/module.mk is unchanged
./mkbuiltins bitfcns.cc data.cc debug.cc defaults.cc dirfns.cc error.cc
file-io.cc graphics.cc help.cc input.cc lex.ll load-path.cc load-save.cc
ls-oct-ascii.cc mappers.cc oct-hist.cc oct-parse.yy octave.cc pager.cc
pr-output.cc sighandlers.cc sparse.cc strfns.cc symtab.cc syscalls.cc
sysdep.cc toplev.cc utils.cc variables.cc ov-base.cc ov-bool-mat.cc ov-cell.cc
ov-class.cc ov-fcn-handle.cc ov-fcn-inline.cc ov-flt-re-mat.cc ov-null-mat.cc
ov-range.cc ov-re-mat.cc ov-struct.cc ov-typeinfo.cc ov-usr-fcn.cc ov.cc
ov-int16.cc ov-int32.cc ov-int64.cc ov-int8.cc ov-uint16.cc ov-uint32.cc
ov-uint64.cc ov-uint8.cc pt-arg-list.cc pt-binop.cc pt-eval.cc pt-mat.cc  >
builtins.cc-t
mv builtins.cc-t builtins.cc

I am attaching a full builtins.cc as I see it on my system.

Hopefully I have explained clearly.

Cheers

(file #24274)
    _______________________________________________________

Additional Item Attachment:

File name: builtins.cc                    Size:2018 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?34725>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]