Re: wxWidgets 2.9 build

On Sun, Jan 23, 2011 at 15:46, Peter Geoghegan
<peter(dot)geoghegan86(at)gmail(dot)com> wrote:
> On 23 January 2011 12:58, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> Why do we ship a copy of FlexLexer.h from a specific version of
>>> flex++? Are we really that sensitive to the differences in Flex
>>> versions? Is the easiest thing to get pgadmin to build after changing
>>> the pgscript grammar to use flex 2.5.33, as perhaps suggested in
>>> ./pgadmin3/pgadmin/pgscript/README?
>>
>> Isn't that part of the "ship the bison/flex output files" thing? We
>> ship lex.pgs.cc parser.tab.cc as well, and that's where the dependency
>> comes from. So we need to ship either both of them or none of them, I
>> think.
>
> Right, I see your point.
>
>> I don't recall exactly why it was, but the README is pretty specific
>> about the fact that it *is* sensitive. So the version used to generate
>> the .cc files should be the same as the one used for the .h....
>
> Actually, I would say that the README isn't very clear on that at all
> - it just indicates that non 2.5.33 Flex will invalidate the shipped
> FlexLexer.h. However, I suppose despite what you've said about
> FlexLexer.h, the fact that we ship what is supposed to be a system
> header makes whether or not we're sensitive to Flex version less
> clear.
>
> We ship a shell script, "parser.sh", that does it all for us. Example:
>
> cd ./.. ... done
> /home/peter/pgadmin3/pgadmin
>
> + Generating Bison output... done
> + Generating Flex output... done
> + Processing Flex output... done
> + Processing Bison output... done
> + Moving Bison header files...
>    + mv pgscript/location.hh include/pgscript/location.hh
>    + mv pgscript/parser.tab.hh include/pgscript/parser.tab.hh
>    + mv pgscript/position.hh include/pgscript/position.hh
>    + mv pgscript/stack.hh include/pgscript/stack.hh
> ... done

Hmm. Perhaps the bug is that parser.sh should also update FlexLexer.h?

> This updates both  lex.pgs.cc and parser.tab.cc . I now run Make
> --ignore, and see errors about various structs only having
> declarations and not definitions available. Here it is:
>
> g++ -DHAVE_CONFIG_H -I. -I..   -I/usr/local/pgsql/include
> -I/usr/local/pgsql/include -DHAVE_CONNINFO_PARSE
> -I/usr/local/lib/wx/include/gtk2-unicode-2.9
> -I/usr/local/include/wx-2.9 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL
> -D__WXGTK__ -O2 -DEMBED_XRC -I/usr/include/libxml2
> -I/usr/include/libxml2
> -DDATA_DIR=\"/usr/local/pgadmin3/share/pgadmin3/\" -Wall
> -Wno-non-virtual-dtor -fno-strict-aliasing -I../pgadmin/include   -MT
> lex.pgs.o -MD -MP -MF .deps/lex.pgs.Tpo -c -o lex.pgs.o `test -f
> './pgscript/lex.pgs.cc' || echo './'`./pgscript/lex.pgs.cc
> In file included from pgscript/pgsScanner.ll:17:0:
> pgscript/pgsParser.yy:109:2: error: ‘pgsExpression’ does not name a type
> pgscript/pgsParser.yy:110:2: error: ‘pgsStmt’ does not name a type
> pgscript/pgsParser.yy:111:2: error: ‘pgsStmtList’ does not name a type

> It's as various #includes are absent from various CPP files. I hack
> the files listed in those various cpp files and add includes (mostly
> the ones in pgsParset.yy, but some others - haven't bothered to
> isolate anything), and everything seems to work fine.

Yeah, certainly looks like missing include file(s) somewhere? Thought
it's weird this has stopped working, since it does work in branch head
- have you changed some global headers? (there are too many things in
general that are included in global headers, imho, which may hide
missing local ones i nsome cases)

(sorry, I've not been following this thread, just got alerteed to it
when dave pointed towards me)

> Now, the only remaining error message is that prevents us from
> compiling the only missing object file, pgsDriver.o, is:
> ./pgscript/utilities/pgsDriver.cpp: In member function ‘bool
> pgscript::pgsDriver::parse_stream(std::istream&)’:
> ./pgscript/utilities/pgsDriver.cpp:49:9: error: ‘class
> pgscript::pgsParser’ has no member named ‘set_debug_level’
>
> The class pgsParser very clearly does not have a member named
> set_debug_level, so it's hard to argue with that.

Well, in git head, it's in parser.tab.cc. So it seems bison generated
it then, and that has changed. The one generated is by Bison 2.3, do
you have a different verison of that as well? Perhaps it's documented
in the release notes for that one how this has changed?

> How would everyone feel about committing my work without Flex/Bison
> changes, and without worrying about how we'll eventually handle OGL?
> I'll verify that I haven't somehow broken wx 2.8 compatibility today,
> and then produce a new patch.

In principle I'm for incremental commits. Assuming the patch itself is
ok of course, I haven't actually reviewed anything :-)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/