Graph broken for vc7.1 after 1.31?
Hi, Sorry if I am missing something - I can't compile (with Visual C++ 7.1) the graph library in the cvs snapshots since a couple of months. The errors are in graphviz_graph_lex.cpp and graphviz_digraph_lex.cpp due to an include of a Unix specific file "unistd.h". Although there is a preprocessor condition YY_NO_UNISTD_H around it, I can't find anywhere this would be defined for non-unix systems. I start the build with this command: libs\graph\build>bjam "-sTOOLS=vc7.1" Will this be fixed to the final 1.32 release? I do remember the graph library worked in 1.31, but with some build tweaks regarding un-/directed graphs. Regards, Christian
Vladimir, You'd regenerated the bison/flex output after 1.31.0, which has caused both this problem and the regression noted by Jeffrey Holle on the users list yesterday. Perhaps we should revert this directory to its 1.31.0 state. We'll deprecate it in 1.32.0 (when, hopefully, we will have a new GraphViz parser that works well) and remove it afterwards. Ok? Doug On Sep 29, 2004, at 3:39 AM, Christian Wahlgren wrote:
Hi,
Sorry if I am missing something - I can't compile (with Visual C++ 7.1) the graph library in the cvs snapshots since a couple of months.
The errors are in graphviz_graph_lex.cpp and graphviz_digraph_lex.cpp due to an include of a Unix specific file "unistd.h". Although there is a preprocessor condition YY_NO_UNISTD_H around it, I can't find anywhere this would be defined for non-unix systems.
I start the build with this command:
libs\graph\build>bjam "-sTOOLS=vc7.1"
Will this be fixed to the final 1.32 release? I do remember the graph library worked in 1.31, but with some build tweaks regarding un-/directed graphs.
Regards, Christian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Doug,
Vladimir,
You'd regenerated the bison/flex output after 1.31.0, which has caused both this problem and the regression noted by Jeffrey Holle on the users list yesterday. Perhaps we should revert this directory to its 1.31.0 state.
It's not so easy :-( I've regenerated the files as part of this commit: 2004-01-26 12:16 vladimir_prus * graphviz_digraph_parser.cpp, graphviz_graph_parser.cpp, graphviz_parser.yy: Fix (or rather workaround) the bug which caused second reading of graphviz file to fail. Looks like the parser is not reenterant. Patch from anynymous user. so if we revert the files back, we'll introduce back a bug. I've just regenerated the files again and Jeffrey's problem is gone. Guess we'd need to #define YY_NO_UNISTD_H to fix the other problem. I've added that to Jamfile and the files seems to still build. Should I commit the regenerated files and Jamfile changes?
We'll deprecate it in 1.32.0 (when, hopefully, we will have a new GraphViz parser that works well) and remove it afterwards.
How the new parser will be implemented? - Volodya
[Moving to the Boost list only] On Sep 29, 2004, at 9:07 AM, Vladimir Prus wrote:
Hi Doug,
Vladimir,
You'd regenerated the bison/flex output after 1.31.0, which has caused both this problem and the regression noted by Jeffrey Holle on the users list yesterday. Perhaps we should revert this directory to its 1.31.0 state.
It's not so easy :-( I've regenerated the files as part of this commit:
2004-01-26 12:16 vladimir_prus
* graphviz_digraph_parser.cpp, graphviz_graph_parser.cpp, graphviz_parser.yy: Fix (or rather workaround) the bug which caused second reading of graphviz file to fail. Looks like the parser is not reenterant.
Patch from anynymous user.
so if we revert the files back, we'll introduce back a bug.
Argh!
I've just regenerated the files again and Jeffrey's problem is gone. Guess we'd need to #define YY_NO_UNISTD_H to fix the other problem. I've added that to Jamfile and the files seems to still build.
Should I commit the regenerated files and Jamfile changes?
Sure. Were you able to check it on VC 7.1?
We'll deprecate it in 1.32.0 (when, hopefully, we will have a new GraphViz parser that works well) and remove it afterwards.
How the new parser will be implemented?
Spirit. Granted, they've dropped support for older, broken compilers, so someone will still be getting hurt by this. Doug
Doug Gregor wrote:
I've just regenerated the files again and Jeffrey's problem is gone. Guess we'd need to #define YY_NO_UNISTD_H to fix the other problem. I've added that to Jamfile and the files seems to still build.
Should I commit the regenerated files and Jamfile changes?
Sure.
Done.
Were you able to check it on VC 7.1?
No. I'd appreciate if you could try there.
We'll deprecate it in 1.32.0 (when, hopefully, we will have a new GraphViz parser that works well) and remove it afterwards.
How the new parser will be implemented?
Spirit.
Is it written yet? Would be interesting to see.
Granted, they've dropped support for older, broken compilers, so someone will still be getting hurt by this.
Right. OTOH, I start to wonder if BGL should drop support for old compilers as well. (borland and vc6 are marked unusable already). There seem to be a lot of workaround inside BGL which means even reading the code hard. - Volodya
On Wed, 29 Sep 2004 18:25:26 +0400, Vladimir Prus wrote
Granted, they've dropped support for older, broken compilers, so someone will still be getting hurt by this.
Right. OTOH, I start to wonder if BGL should drop support for old compilers as well. (borland and vc6 are marked unusable already). There seem to be a lot of workaround inside BGL which means even reading the code hard.
More and more I've come to believe that the time has come to start ignoring these old compilers boost-wide. I've taken the approach of ignoring them for any new features I add -- as long as things that worked in the last release continue to work. Even that, in my experience, becomes a pain rather quickly -- I'm guessing at least 1/3 of our time has gone into backward compatibility while addind wide char i/o support and such... Jeff
On Sep 29, 2004, at 9:25 AM, Vladimir Prus wrote:
Were you able to check it on VC 7.1?
No. I'd appreciate if you could try there.
I'll try to do so later.
We'll deprecate it in 1.32.0 (when, hopefully, we will have a new GraphViz parser that works well) and remove it afterwards.
How the new parser will be implemented?
Spirit.
Is it written yet? Would be interesting to see.
I think the parser is written but the semantic actions are not, so it isn't functional yet. We're trying to unify on some kind of system for dynamic properties, so that we can deal with reading in arbitrary vertex/node attributes. I have a GraphML parser that handles dynamic properties, which hopefully will also work well in the new GraphViz parser. If I get some time post-1.32.0 (hah!), we'll try to get all those bits in.
Granted, they've dropped support for older, broken compilers, so someone will still be getting hurt by this.
Right. OTOH, I start to wonder if BGL should drop support for old compilers as well. (borland and vc6 are marked unusable already). There seem to be a lot of workaround inside BGL which means even reading the code hard.
We promised to keep the parts of the BGL needed for the Python lib in working order. But I've marked borland and vc6 unusable because they've never really been usable and are a huge maintenance burden. Doug
Doug Gregor wrote:
How the new parser will be implemented?
Spirit.
Is it written yet? Would be interesting to see.
I think the parser is written but the semantic actions are not, so it isn't functional yet. We're trying to unify on some kind of system for dynamic properties, so that we can deal with reading in arbitrary vertex/node attributes. I have a GraphML parser that handles dynamic properties, which hopefully will also work well in the new GraphViz parser. If I get some time post-1.32.0 (hah!), we'll try to get all those bits in.
Ok.
Granted, they've dropped support for older, broken compilers, so someone will still be getting hurt by this.
Right. OTOH, I start to wonder if BGL should drop support for old compilers as well. (borland and vc6 are marked unusable already). There seem to be a lot of workaround inside BGL which means even reading the code hard.
We promised to keep the parts of the BGL needed for the Python lib in working order.
If Python uses only specific type of a graph, say adjacency_list<vecS, vecS, directedS, ......>, then it's possible to provide a vc6-friendly definition of that type, and clean up implementation for all the rest types. Just a though, for now -- I don't feel right changing all BGL internals *at the moment*. - Volodya
participants (4)
-
Christian Wahlgren -
Doug Gregor -
Jeff Garland -
Vladimir Prus