Python vs. CMake for Build tool

[Nava2]

I'm trying to fix the python bootstrap.py, but I feel like I'm reinventing the wheel trying to have it find Lua vs. LuaJIT.

Is there a reason for using a custom python script over something like CMake? CMake will happily generate Ninja build files.

[nabijaczleweli]

Yes, there is. CMake is utter shit.

[Nava2]

That's neither an answer, nor helpful.

[nabijaczleweli]

It is the answer The Lounge (and, by membership, ThePhD) will give you

[ThePhD]

Erm... Lounge affiliation or not, as I explained in #23, using CMake is not practical because this library doesn't have any build steps.

[ThePhD]

Out of curiosity, what're you trying to "build" with Sol? Is it just the automation of finding the right lua version to get bundled with it? IMHO, I would like that to be the user's choice, and not a feature (and eventual problem) we have to graft onto the library (as Sol is meant to be lua-version-agnostic, for the most part).

[Nava2]

My research (for my masters.. not as the PhD level 😉) has Lua as a primary component and needs to be tested and run cross-platform. So, finding Lua is always a pain. This is something CMake does really well.

[Nava2]

Oh, and I just re-read what you wrote about Lua versions, you're correct. The Lua Version is only required when building the tests or examples. Otherwise, it never asks nor requires it. That being said, I would figure Intellisense and other tools when developing sol2 would have some problems if you didn't.

[ThePhD]

After thinking about this a bit more, I think I'm going to have to stick with the python. The primary reason is that it's simple and will continue to be for automating our test suite. I also want to be careful because, when we hit the 2.0.0 tag (probably in the next 2 weeks), what the release story will be is literally is:

"We ran single.py and you just need to download the amalgamated sol.hpp to get going. Put it anywhere you like. Enjoy."

CMake doesn't really help with that story, so in the end it'd just be something that we use to run our tests... so then we have to ask ourselves "is this something we want for running the tests / examples?"

And at the moment... nah, not really. Though I can see how easy it is to get going, I am unfortunately not very good at CMake and am focusing on writing the docs / preparing for v2.0.0 release. We'll keep the python zaniness for now, and just request that users who want to do things like find the right Lua version should consult their specific platform / build system for it.

[Nava2]

As a last attempt to change your mind, since I need to be using this for the foreseen future, I don't mind maintaining the build.

I hadn't got around to it, but I was planning on adding the single header to cmake. I think what stopped me was the script is currently broken.