Overhaul Makefile build process

[solemnwarning]

This is a pretty big (and potentially contentious) change, but I've reworked the Makefiles for wxLua with the following goals:

• Allow building with a host-provided Lua
• Allow building wxLua targets as part of a larger project
• Generate bindings on demand

In addition to the above, I made the following changes while refactoring:

• Move public headers into an include directory to simplify use from an external project
• Move defaults from wxluasetup.h to wxluasetup-defaults.h which can be included from a user wxluasetup.h
• Updated CMake build scripts to build bindings on demand too

[solemnwarning]

Hi @pkulchenko,

Good to see you active on this project again. What are your initial thoughts on this change? If you like them in principle I'll rebase this PR and pull in some newer build changes from my fork too.

[pkulchenko]

Hi @solemnwarning, yes, I'm interested. I realize that it's an ambitious change, but I like the direction and the simplification that it may potentially bring. I'll check on the rebased PR. Thank you!

[solemnwarning]

@pkulchenko,

I've rebased it, made some further fixes to the Makefile/CMakeLists and made an initial pass at a GitHub Actions workflow to verify the myriad of configurations, which can be seen running here: https://github.com/solemnwarning/wxlua/actions/runs/34025706469

[pkulchenko]

Hi @solemnwarning, thank you for the rebased PR and the added github actions! I'm still checking, but have a couple of questions about the new bindings approach. What's the motivation behind regenerating them on the fly and always overwriting generated files. My concern is that troubleshooting a build process is already fairly complex and adding a step that requires bindings to be regenerated will further complicate it. My understanding is that the rest of your changes are independent from this regeneration. Is that not the case?

[solemnwarning]

My motivation was ensuring that the bindings are always up to date - I've seen them get desync'd plenty in this repo and IMO build artifacts/intermediates don't belong in the source tree.

The change to genwxbindings.lua to make it always update the source files is because that's what most "compilers" do and what how build systems like Make expect them to behave - Make/CMake will already only update the bindings when one of their inputs changes, so there's no reason for genwxbind.lua to avoid touching the file.

The Makefile(s) were in a pretty hairy state before I started on this, so a lot of restructuring/fixes on them in particular got done at the same time just to get things to a state where they worked well enough to use as a base.

[pkulchenko]

Do you think we can split them into two PRs? I agree that people sometimes miss committing updated bindings, but this is an easy problem to fix. I'm still concerned about complicating the build process and requiring a Lua interpreter to process the binding (yes, I recognize the irony). Maybe I just need to try it a couple of times to see the effect...

[solemnwarning]

I'm not really sure how much of this can be split off into a separate PR - refactoring the makefiles touched almost everything due to the previous state of them. In the long term there's more I can do to simplify the build system, but am trying to keep this PR somewhat contained.

EDIT: The GitHub Actions workflow is self-contained if you want that separated.

[pkulchenko]

@solemnwarning, I tried compiling using the new approach, but it didn't work for me on Windows. I had to replace linux wit mingw and still ran into issues with compilation. What's your expectation about making the process more configurable? As far as I understand, the idea behind using cmake was to better configure the build process to match the environment.

If we want to start with something portable, we can get cosmopolitan-compiled lua 5.1 (to avoid building it from scratch for the build process) and use something like premake (https://github.com/premake/premake-core/) to run the build. I'm not sure if the effort is worth it though.

[solemnwarning]

My original goal here was to get the Makefile-based build system to a point where it could usefully be embedded from another project, and to avoid having to keep the intermediates cluttering up the source tree. If you look here, you can see I've essentially duplicated a lot of things which should really be exposed by wxLua (e.g. source files names) and added a sub-make invocation to generate the bindings, which has its own set of annoying edge-cases when developing wxLua in-tree since Make isn't aware when things need to be rebuilt.

Once that was done, I naturally had to fix up the CMake-based build system to also generate the bindings to get benefit from the changes, and also fixed up some issues with configuration (e.g. Lua detection) in both build systems to get it working.

Going forward, there's more cruft which can be removed from both build systems (for example the CMake configuration has a whole alternate path for compiling the bindings (core, aui, etc) independently rather than into a single wxbind library... which doesn't even work so I assume no one is using it.

I'm not sure what switching to premake would give compared to CMake - build systems are such a personal preference and I personally sit in the "use a build system" (e.g. Make, MSBuild, etc) rather than the "use a build system that generates a build system" (e.g. CMake) camp.

I can look into why it isn't working on Windows, I think I got my branch working for someone on Windows a while ago but things may have changed since then, and once the CI workflow is configured with more targets it will obviously be a lot more stable going forwards.

Which toolchain, wxWidgets version and build system were you trying to use on Windows?