If you have any questions or feedback, we’ll be happy to discuss.
We are looking for new contributors to help us get over the finish line faster. If anybody reading this is interested, please let me know, I am happy to meet over video to explain the details and get you up to speed. There are many opportunities to contribute (semantics, LLVM backend, other backends, C++/Python/Julia interoperability, runtime library implementation, test suite, documentation, etc.).
Do you plan a FreeBSD port? Trying to build it currently requires to pull the whole FreeBSD source to get the LLVM headers. And as base is still at LLVM 10, I’m not even sure it will work. I’ll try it later with a dedicated build jail.
I’ll be happy to support FreeBSD officially but I would need some means to test it. To start, simply compile LFortran without LLVM:
wget https://lfortran.github.io/tarballs/release/lfortran-0.14.0.tar.gz
tar xzf lfortran-0.14.0.tar.gz
cd lfortran-0.14.0
cmake -DWITH_LLVM=no .
make -j8
ctest
You only need a C++ compiler and cmake. Let me know if this works. If anything fails, either in the build or tests, then let’s fix it.
As @wyphan said, unfortunately fpm is not available on Windows yet in Conda. So just install lfortran and jupyter using conda, that will work (we test it at our CI), and you can at least test jupyter notebook, or run lfortran from a command line by hand.
Unfortunately lfortran also currently does not work with cmake on Windows (only on Linux and macOS).
The alternative is to download the statically linked binary from the release page or if you are using the MSYS2 package manager, install fpm via pacman -S mingw-w64-x86_64-fpm.
Yeah, that’s using some C++17 filesystem support. Can you disable it in CMake and comment out the offending lines? That should be doable. We’ll then figure out a workaround for the functionality that we need.
diff --git a/src/bin/CMakeLists.txt b/src/bin/CMakeLists.txt
index 5678d6bb4..8fd56088b 100644
--- a/src/bin/CMakeLists.txt
+++ b/src/bin/CMakeLists.txt
@@ -1,10 +1,6 @@
add_executable(lfortran lfortran.cpp)
target_include_directories(lfortran PRIVATE "tpl")
target_link_libraries(lfortran lfortran_lib)
-if (UNIX AND NOT APPLE)
- # This is sometimes needed to fix link errors for CLI11
- target_link_libraries(lfortran stdc++fs)
-endif()
if (LFORTRAN_STATIC_BIN)
if (CMAKE_SYSTEM_NAME STREQUAL "Linux")
# Link statically on Linux with gcc or clang
@@ -134,7 +130,3 @@ endif()
add_executable(cpptranslate cpptranslate.cpp)
target_link_libraries(cpptranslate lfortran_lib)
-if (UNIX AND NOT APPLE)
- # This is sometimes needed to fix link errors for CLI11
- target_link_libraries(cpptranslate stdc++fs)
-endif()
gfortran 1.f90 2.f90 will create an executable if the source files comprise a complete program, and other compilers work the same way. For LFortran you must do
The first prints the C++ code and the second option tries to compile it. Currently it requires the Kokkos C++ library for arrays. We can improve this in various ways, such as not using Kokkos optionally, etc.
Using the x86 backend:
lfortran --backend=x86 examples/expr2.f90
This backend produces a Linux ELF x86 (32bit) binary. The compilation should succeed for you (as it does for me on macOS), but obviously the binary probably won’t run in FreeBSD. But we can improve it to work if there is interest. The x86 backend is more of a prototype still, so only very simple things work.
Get LLVM working in FreeBSD
What LLVM versions are available? We currently don’t actually compile with the latest LLVM 12 version, and I think we require LLVM 11. I think it would not be difficult to support several latest LLVM versions. You mentioned the latest LLVM version available is LLVM 10. I think we can support that and test it at our (Linux) CI.
It seems the 3) would be the easiest as we are currently focusing on the LLVM backend the most. Can you try to compile it with the LLVM from FreeBSD and report back? If the issue is just some errors because the LLVM API is tiny bit different, that we can fix for sure using ifdefs and CI tests in Linux.
While we are at this topic: do you know how to best test FreeBSD at our Continuous Integration? We can run any Docker container on Linux (gitlab.com runners), we can run on Windows (AppVeyor) or macOS (using Azure). If there was a way to test on FreeBSD, I’ll add it in and fix things so that they just work. I can see that GitLab CI supports FreeBSD: Install GitLab Runner on FreeBSD | GitLab, so now I just need to get it running somewhere. I found this online service: FreeBSD VMs - Cirrus CI.
Thanks. LFortran works with LLVM 11, so that should work.
I’ll try to figure out a CI solution, because otherwise what would happen is that people fix it, and then we break it again as we develop.
I am actually considering just buying a few computers, installing various systems on them and run a GitLab CI runner on them all the time and use that as part of our CI testing.
There is a FreeBSD solution with Cirrus CI, I used their service in the past to make some checks on FreeBSD. The images do not contain any software by default, means you have to invest some time to get a proper caching setup or you will spend too much time installing GBs of packages.
It may not be necessary to target LLVM 10, as FreeBSD 13 has already moved on to LLVM 11. I’ll try it again with installed LLVM 11 sources once I’ve upgraded from 12 to 13.
On this note: would people like if we maintain compatibility with multiple versions of LLVM, and how many?
We could do for example the last three (so today that would be 12, 11, 10).
My experience with LLVM is that they change the API with each release, but the changes are relatively minor, so we can handle it with a preprocessor. One big breaking change is how they handle JIT, we still use an older version that got completely removed in LLVM 12, so we need to rewrite it.
I was thinking simply supporting the latest version at our CI on all platforms, and then add two older versions but only test those on Linux. Otherwise it would slow down especially the Windows builds, and I am hoping to avoid that.