Rework the installation process #534
Conversation
hugomg
force-pushed
the
lua-core
branch
9 times, most recently
from
b6cb540 to
b59124b
Compare
| @@ -0,0 +1,623 @@ | |||
| -- /* | |||
There was a problem hiding this comment.
returning C code from a Lua code is a bit weird when viewing in a text editor 😅
How would you feel if this was a regular old C file and we read it using io before returning the code?
There was a problem hiding this comment.
Yeah, it is certainly awkward. I have to manually switch the syntax highlighting color in my editor. The main problem is where to install the file, and how to find the path to the file after it is installed. I believe that with Luarocks you need to use a third-party library: https://github.com/hishamhm/datafile. I didn't want to add a dependency just so we could use this one file, but maybe it's clearer than the current hack... What do you think?
There was a problem hiding this comment.
I'm also in favor of having inline C code over adding a dependency.
But I also wonder why we can't just do io.open("./pallene.h", "r") to read the header.
There was a problem hiding this comment.
One of the things I want to achieve with this PR is to no longer care about the current working directory (issue #16). From now on, using relative paths is forbidden.
We are moving that to a separate repository
This makes it easier to compiler the generated C code because it no longer needs to #include the pallene_core.h, passing the right -I flags. We also don't have to compile & install the Pallene standard library, meaning that the Pallene compiler is now a pure Lua project. The catch here is that we now statically link the Pallene standard library, which adds up to 10 KB of extra size to every binary produced with Pallene. I think that is an acceptable tradeoff for now, to keep things simple. If this turns out to be a problem later then we can reintroduce the pallenelib.so.
As well as some old files that were also missing...
Dunno why these showed up now, but might was well.
Since we have custom Lua & Luarocks now, we can't use the leafo actions.
|
I think I'm happy enough with this branch to remove the "draft" flag now. I think it is a great step towards making easier to install Pallene, but it does have some quirky aspects. For example, you need to separately install our patched version of Lua... Would love to hear if this kind of thing is OK or if it runs into problems for any of you. |
|
I'm on a macbook rn (work machine). |
|
Cool. The next step I'm planning after this PR is #516 and it will be very helpful to be able to test that on a Mac. |
This pull request allows the Pallene compiler to be called from any directory, not just the root of the repository. This fixes #16. Hooray! To accomplish this, I did the following things:
The first thing I did was move the custom Lua interpreter to a separate repository. This custom Lua only exposes the Lua internals and can be used for both Pallene and LuaAOT. This custom Lua only needs to be updated sporadically, whenever a new version of Lua comes out.
The second thing I did was to move all the things in the pallene_core.c into the pallene_core.h. Effectively, this statically links the pallene standard library into the generated modules. Maybe it is a bit bloated, but it has the advantage that when we build pallenec itself, we don't need to compile any C code.
The third thing I did was to copy paste the contents of the pallene_core.h into the generated C code, instead of using an #include directive. (Btw, I also renamed it from pallene_core.h to pallenelib.lua) This produces a larger C file but has the advantage that we don't need to worry about passing any -I flags to the compiler.
Some limitations that we can fix later: