Menu
▾
▴
#13 Depends on flex >=2.5.31, but Cygwin has only 2.5.4a
Current trunk can't be compiled in a Cygwin environment.
One reason is the dependency of the SVF parser compilation on modern (post 2003) flex 2.5.31 or newer.
Cygwin provides only 2.5.4a, which complains about unknown "%option: bison-locations". I'm no flex/bison expert... is it possible to modify the code so that it would compile with 2.5.4? I know, 2.5.4 is from 1995, but for some reason Cygwin doesn't have the new one. It seems there has been no update since 2.5.4a was announced:
http://www.cygwin.com/ml/cygwin-announce/2003-09/msg00112.html
Logged In: YES
user_id=156321
Originator: NO
In general, I don't like the idea to modify code (and probably make it more complex and less maintainable) just because of some legacy software (ok, we're dealing with Windows in this particular case ;-).
On the other hand, I didn't introduce these fragments in the lexer - they were added with a patch from a third party. Thus I can't offer a solution out of the box.
Simple solution: remove the offending parts
Less simple: make them conditional based on the detected flex version
Discouraged: re-code them from scratch
Logged In: YES
user_id=478715
Originator: YES
You're right, it was added in revision #706 as "[1194137] better SVF diagnostics" ...
http://urjtag.svn.sourceforge.net/viewvc/urjtag?view=rev&revision=706
... for printing info about the location of SVF code causing problems
I just assigned it to you because it's somehow related to the SVF player. Reassigning to "none"... maybe I find time for a solution in the future when I take a more serious attempt at compiling under Windows.
Logged In: YES
user_id=156321
Originator: NO
Keep it assigned to me. I was just a bit clueless in the beginning, that's what I wanted to express.
I just started to look at it and evaluate the conditional build solution currently. However, another option popped up: How about checking in and distributing the flex and bison outputs? Then users wouldn't have to worry about these tools and we (I?) could use the latest&greatest versions after a modification to the parser/lexer source.
Logged In: YES
user_id=478715
Originator: YES
We could handle the generated files just as it is commonly done with "configure": have it in a tar.gz for download, but not in the repository. Having files in the repository that are [or: should be] recreated from source during compilation can become confusing. The svn:ignore property doesn't help (unless the versioned files were available from a different place)
Logged In: YES
user_id=156321
Originator: NO
I get your point, but the *.c files for lexer and parser are derived files. Derived, but still sources. Not sure which path I'd prefer.
But maybe your idea of adding them to the download tar.gz is a good tradeoff.
With a small modification to svf/Makefile.am the derived files aren't deleted with 'make clean'. Furthermore, a 'make dist' seems to be intelligent enough to build the derived files and to add them to the release tar.gz - excellent!
Summarizing
* problematic features are conditionally enabled based on configure's flex detection
-> Cygwin's flex will run without error
* 'make dist' generates the derived parser&lexer files
-> they are part of a release
-> full diagnostics with Cygwin as it compiles the derived *.c files
* when checked-out from repo, Cygwin compiles result in reduced diagnostics
Guess I could live with this.
Logged In: YES
user_id=156321
Originator: NO
configure will detect now that Cygwin's flex is an old version and sets switches that exclude the bison-locations feature from svf_flex.l
Please check whether revision 783 fixes your problem.
Logged In: YES
user_id=478715
Originator: YES
It works perfectly when building from SVN. Depending on flex version the right options and code are chosen. But building from distributed.tar.gz fails on a system where flex is "the other" version as on the system where the tar.gz (and svf_flex.c) was created.
That's because there are some #ifdef(MODERN_FLEX) sections in svf_flex.c. MODERN_FLEX is defined by configure on the current system; i.e. it might be different from the setting on the system where flex was run. Solution: the #ifdef sections in svf_flex should not use the MODERN_FLEX definition from configure, but rather something that was embedded in svf_flex.c when flex was run. For example, the version number is embedded by flex. I'll fix that...
Logged In: YES
user_id=478715
Originator: YES
#830: Moved the HAVE_MODERN_FLEX definition from configure to svf_flex.l itself (flex puts some definitions about its version at the top of svf_flex.c, and HAVE_MODERN_FLEX is now derived from these definitions). The task of "configure" is now just to decide whether flex should be passed the --bison-locations argument.
One thing remained (maybe) confusing: A "make clean" will probably wipe the svf_flex.c file, therefore building after make clean would yield a different result than building from a freshly unpacked distribution.tar.gz. I try to regard these files as MAINTAINERCLEANFILES only, not simple CLEANFILES (in src/svf/Makefile.am).