Can't compile Silice on Arch Linux about silice HOT 14 OPEN

from silice.

I used the master branch.

from silice.

from silice.

from silice.

An ArchLinux package would be great! Thanks @rob-ng15 for testing ; on a fresh Archlinux (gcc 13.2.1 20230801) "master" also compiled on my side. @Popolon looking at the messages it seems like tighter security (warnings considered errors), maybe a different default g++ setting? I definitely will fix those, but would help to be able to reproduce on my side. I'll investigate!

from silice.

I pushed a fix (both in master and draft). I enabled the warning as error in the CMakeLists.txt (using -Werror=...) such that I can trigger the same compiler behavior. There might be others, please let me know how it goes.

(I'll likely enable -Werror to resolve all warnings, unfortunately a few are in third party libs).

from silice.

@rob-ng15 I have both Lua version, but it's not related at all (and looks like Silice use statically linked liblua.a), that's an error related to type/cast, and strong default warning policy.

@sylefeb Thank you very much, this resolved the problem. Everything is compiled. I will update this ticket with the informations about the Arch package, as soon I finished it.

from silice.

The package is now available at : https://aur.archlinux.org/packages/silice-git

It looks like, from the sources, only silice binary is needed to be installed in bin/ can you confirm?

from silice.

I had more time to test the package, libSL-small had to be installed in /usr/src/libs/ and 2 .py scripts in /usr/bin, I can now synthesize and run examples with verilator.

from silice.

Hi, sorry for the slow answer, indeed the Python scripts are needed to build, good catch for LibSL-small (this is because the verilator framework requires a compilation every time). The frameworks folder is also used by the build system, it contains board definitions, code templates and the verilator framework sources. If I understand correctly the PKGBUILD these might be missing currently?

However if you can successfully run verilator examples these are found somehow? To help see which folders are used, when a build occurs (eg. make verilator in projects/vga_test) the detected folders are displayed, see below:

from silice.

I just tested to synthesize blink example in learn-silice folder and it worked with Verilator.

for framworks, I noticed in sources (confirmed by a strings silice| grep frameworks in binaries), that the path is ../frameworks, relative to the binary.

./src/SiliceCompiler.cpp:    frameworks_dir = std::string(LibSL::System::Application::executablePath()) + "../frameworks/";
./src/SiliceCompiler.cpp:  CONFIG.keyValues()["frameworks_dir"] = frameworks_dir;
./src/SiliceCompiler.cpp:  CONFIG.keyValues()["templates_path"] = frameworks_dir + "/templates";
./src/SiliceCompiler.cpp:  CONFIG.keyValues()["libraries_path"] = frameworks_dir + "/libraries";

In should be in /usr/share/silice/frameworks instead in a Linux Standard Base way. The pass can be given to the binary using --frameworks_dir= parameter, but it should probably be better to have this at compile time or a LSB way by default, on Linux platforms.

from silice.

I just updated package to put frameworks in /usr/share/silice/frameworks and a patch to change both silice binary and silice-make.py with this as default path.

from silice.

Sounds like a good approach for now, thanks! I'll look into using CMAKE_INSTALL_PREFIX correctly (also relates to #240), which hopefully could help packaging without creating trouble for local builds.

from silice.

Hi Everyone, this issue should be fixed by the changes in the draft branch. Everything is now installed in the usual /usr/local/bin and /usr/local/share/silice directories.

I also revised the 'getting started' scripts and created a ./get_started_linux.sh script that I tested under Ubuntu (18, 20), Debian, Fedora, ArchLinux.

I will merge to main very soon, please let me know if you see anything wrong.

from silice.