diff options
Diffstat (limited to 'how_to_organize_your_lua_project.html')
-rw-r--r-- | how_to_organize_your_lua_project.html | 20 |
1 files changed, 11 insertions, 9 deletions
diff --git a/how_to_organize_your_lua_project.html b/how_to_organize_your_lua_project.html index 63d952d..4a25626 100644 --- a/how_to_organize_your_lua_project.html +++ b/how_to_organize_your_lua_project.html @@ -3,7 +3,7 @@ <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta name="author" content="aki"> -<meta name="tags" content="tutorial, structure, organizing, lua, project, howto, guide"> +<meta name="tags" content="tutorial, structure, organize, organizing, lua, project, files, howto, guide"> <link rel="icon" type="image/png" href="cylo.png"> <link rel="stylesheet" href="style.css"> @@ -13,7 +13,7 @@ <article> <h1>How to Organize Your Lua Project</h1> -<p class="subtitle">Published on 2021-01-07 15:45:00+01:00, last modified on 2021-08-07 14:07:00+02:00 +<p class="subtitle">Published on 2021-01-07 15:45:00+01:00, last modified on 2022-01-26 19:20:00+01:00 <p>From time to time I hear complaints about how Lua handles modules. Here and there I see and even answer myself questions regarding <code>require</code> and adjusting the paths in <code>package</code> to allow some desired behaviour, with the most prominent issue of relative imports that always work. @@ -25,7 +25,7 @@ mechanism in Lua: <a href="https://www.lua.org/manual/5.4/manual.html#pdf-requir <img src="how_to_organize_your_lua_project-1.png" alt="lua hierarchy"> -<h2>How <code>require</code> handles paths</h2> +<h2>How Does <code>require</code> Handle Paths</h2> <p>Both <code>package</code> and <code>require</code> are surprisingly interesting tools. At first glance they are simple. When you look into them, they are still understandable while gaining some complexity that doesn't reach unnecessary extremes. They are elegant. @@ -59,7 +59,7 @@ However, in our case this knowledge will suffice. <p>If you are curious how exactly path is loaded be sure to check out <a href="https://www.lua.org/source/5.4/loadlib.c.html#setpath"><code>setpath</code></a>. -<h2>Endgame</h2> +<h2>Production Environment</h2> <p>To prepare for development, we need to know where we are heading. First step is to consider the execution environment. Of course, this and packaging are journeys on their own, so let's just look at two common examples: an application that uses some framework that uses Lua (e.g. a game made in <a href="https://love2d.org/">LÖVE</a>) and a @@ -81,7 +81,7 @@ use the environmental variables to prepare for development. If you run your appl then Lua will have access to your modules no matter where it is run. Additionally, it will be consistent with the target environment and won't need any additional hacks. -<h2>Development environment</h2> +<h2>Development Environment</h2> <p>All this talk comes down to: set <code>LUA_PATH</code> in your development environment so that it includes your project files even if they are not installed in system. A simple approach is to source following in each session: <pre> @@ -117,7 +117,7 @@ results</strong>.</p> <img src="how_to_organize_your_lua_project-2.png" alt="a random whale"> -<h2>Organizing your files</h2> +<h2>How to Structure Your Lua Project Files</h2> <p>Finally, this is what we're waiting for. Assume you have a directory that is a parent of all of your project files. We'll call it a project <strong>root</strong>. Usually, this is also root directory for your version control system, be it git or anything else, and for other tools such as building systems or even entire IDEs. @@ -189,13 +189,15 @@ $ find . ./Makefile ./README $ cat Makefile -PREFIX?=/usr/local/lib/lua/5.4 +PREFIX?=/usr/local +LIBDIR?=$(PREFIX)/lib +LUADIR?=$(LIBDIR)/lua/5.4 all: @echo Nothing to be done install: - cp -r hello $(PREFIX) + cp -r hello $(DESTDIR)$(LUADIR) uninstall: - rm -fd $(PREFIX)/hello/* $(PREFIX)/hello + rm -fd $(DESTDIR)$(LUADIR)/hello/* $(DESTDIR)$(LUADIR)/hello </pre> <p>As you can see <i>Makefile</i> in this example has targets for installation and removal of the package. The structure again is simple. Root works as part of the resolution path and so our module is placed in it's own directory named after |