No Makefile in . dir after running .configure, clang errors after running make in vhdlpp dir. about yodl HOT 7 CLOSED

Do you have access to an older version of clang? If yes, does the error still exist? Based on the compiler error that you posted, I cannot really tell you a constructive presumption about the reason of the error. architec.h was included by vhdlpp from the Icarus Verilog project...

from yodl.

Just saw the issue as an interested observer of the repository. I notice that you compile architec.cc with --std=c++14. Note that std::gets was deprecated in C++'11 and removed from C++'14:
http://en.cppreference.com/w/cpp/io/c/gets
Consequently, you see an error message once someone tries to use std::gets. In your case, you link to the C++ standard library provided by g++-4.8's libstdc++-4.8, which does not yet contain support for C++'14. So this seems to be a toolchain issue. To fix it, try to install and use libc++ in the version, which matches your clang++ compiler.

from yodl.

Thanks for the suggestions. I tried some older versions of clang (3.3 / 3.4) but apparently these are not compatible with c++14. When I use c++11 as stdlib, I get quite a bit further (with some fixes), unforunately eventually decltype(auto) is used, which only works in c++14 as far as I am aware? I could start compiling either with c++14 or c++11 depending on which one works for which file, but I guess I am mostly just wondering whether what I am doing is even useful, i.e. do I need the files in ./vhdlpp for yodl to work?

from yodl.

If the source code relies on C++'14 features, it is best to compile all files against this standard. However, to make that work not only your compiler needs to support C++'14, which clang++ >= 3.4 do, but also your standard C++ library, which libstdc++-4.8 does not, but libc++ >= 3.4 do. So my suggestion would be to install the libc++ development package (Debian: libc++-dev) and try to link against it by adding the following compiler switch -stdlib=libc++. Installing g++-4.9 and libstdc++-4.9 or above and compiling with this toolchain might also be worth a try.

from yodl.

Tried libc++ dev version with c++11 for stupid reasons, c++14 works fine with it. Now I have dynamic cast and static cast errors though:
`clang++-3.5 -I. -I.. -I../libmisc -Isimple_tree -Imach7 -Imach7/patterns -Icatch -I/usr/local/share/yosys/include -I/usr/lib/libffi-3.2.1/include -I/usr/include/tcl8.6 -DYOSYS_ENABLE_READLINE -DYOSYS_ENABLE_PLUGINS -DYOSYS_ENABLE_TCL -DYOSYS_ENABLE_ABC -DYOSYS_ENABLE_COVER -D_YOSYS_ -DHAVE_CONFIG_H "-ggdb" "-O0" "--stdlib=libc++" "--std=c++14" "-g" -Wall -Wextra -Wshadow -c expression_gendot.cc -o expression_gendot.o

expression_gendot.cc:27:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:29:24: error: dynamic_cast from rvalue to reference type 'stringstream &' (aka 'basic_stringstream &')
{"value", (dynamic_cast<stringstream&>(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
expression_gendot.cc:37:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:39:24: error: dynamic_cast from rvalue to reference type 'stringstream &' (aka 'basic_stringstream &')
{"value", (dynamic_cast<stringstream&>(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
expression_gendot.cc:47:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:56:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:74:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:76:23: error: dynamic_cast from rvalue to reference type 'stringstream &' (aka 'basic_stringstream &')
{"unit", (dynamic_cast<stringstream&>(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
expression_gendot.cc:78:29: error: dynamic_cast from rvalue to reference type 'stringstream &' (aka 'basic_stringstream &')
{"time value", (dynamic_cast<stringstream&>(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
expression_gendot.cc:92:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:101:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:115:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:124:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:145:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:158:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:166:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:180:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:192:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
expression_gendot.cc:205:30: error: non-const lvalue reference to type 'basic_stringstream<[3 * ...]>' cannot bind to a temporary of type 'basic_stringstream<[3 * ...]>'
{"node-pointer", static_cast<stringstream&>(
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
`

Apparently something went wrong in the c++14 implementation here, because it works fine with c++11 ....

Unfortunately, even if I keep compiling with c++11 and c++14 depending on what combination works, I get to the point where neither combination works, as apparently clang does not support auto functions with are not templates?

`clang++-3.5 -I. -I.. -I../libmisc -Isimple_tree -Imach7 -Imach7/patterns -Icatch -I/usr/local/share/yosys/include -I/usr/lib/libffi-3.2.1/include -I/usr/include/tcl8.6 -DYOSYS_ENABLE_READLINE
-DYOSYS_ENABLE_PLUGINS -DYOSYS_ENABLE_TCL -DYOSYS_ENABLE_ABC -DYOSYS_ENABLE_COVER -D_YOSYS_ -DHAVE_CONFIG_H "-ggdb" "-O0" "--stdlib=libc++" "--std=c++14" "-g" -Wall -Wextra -Wshadow -c clock_edge_recognizer.cc -o clock_edge_recognizer.o

In file included from clock_edge_recognizer.cc:10:
In file included from ./simple_match/include/simple_match/simple_match.hpp:399:
./simple_match/include/simple_match/implementation/some_none.hpp:161:17: warning: unused parameter 't' [-Wunused-parameter]
auto get(T&& t) {
^
error: debug information for auto is not yet supported
1 warning and 1 error generated.
`

But I heard that this enitre part of the code will be replaced in the future anyway....

from yodl.

But I heard that this enitre part of the code will be replaced in the future anyway....

You need to know that I managed to hack YODL on top of the vhdlpp sources which In turn had been hacked on top of an incomplete parser for VHDL, and by "incomplete" I actually mean bluntly incorrect, because it simply can not parse VHDL in its entirety. So yes, to answer your question, it must be replaced in future versions. Not only this code, but probably all of the parser, lexer and the AST structures, because all of that had been derived from the vhdlpp (C++98) sources.

There is a lot of interest in this project. I am very grateful of that.
But honestly, I am daunted by the amount of work required to make YODL into a working vhdl frontend.

Contributions very welcome though.

from yodl.

Thanks for letting me know :)

from yodl.