wren
wren copied to clipboard
wren-lang
Add a CMake project
This adds a CMake project to make it easy to embed Wren in other applications using CMake...
add_subdirectory(wren/projects/cmake)
target_link_libraries(myproject PUBLIC wren)
This should all probably be auto generated. Is there a reason that's not a possibility?
I misunderstood "auto generated". Premake5 unfortunately doesn't have CMake support out of the box. This CMake definition file is pretty minimal, and is relatively easy to update as needed. Don't see a need to premake/auto generate it.
I like this idea and also have ideas on improving it. Is this going to merge?
Really there isn't an extension or anything?
Don't see a need to premake/auto generate it.
The need is long term maintenance and the Cmake getting out of sync with all the others. Right now a single easy script updates every single build system.
What ever the build system, it does requires maintenance and integration.
Cmake is more popular than premake. But both of them have at least one critical problems because of the supported systems (mostly because of windows) where it is not possible to generate a static and dynamic library of the same name. And because of that there is no ideal solution, that also conform to Unix based systems naming conventions.
Cmake is more popular than premake.
So it's an alternative? That's interesting if it supports all the same platforms, I'm not sure that was clear. I'm not sure maintaining both CMake & premake long term makes a lot of sense though. I'm not sure why the issue isn't named "switch from premake to cmake" though.
I think the real problem here is a popular contest. And considering the issues of CMake and premake I know, I think premake is a bit more superior because it is newer, more low level and more easily extensible because of the language. But having toyed with both, some built-in concepts/rules force some workflow that are really hard to customize.
premake was a pain to get working initially on Mac (homebrew needed lots of handholding), but I've had 0 issues with it since.
I downloaded the prebuild version of premake and have no problems. Also I love that they use a simple language like lua to the configurations.
A wild idea would be making a wren version of premake xd.
wrenmaker or something :)
I am not opposed to use CMake either, but that desition would depend on the maintainers.
I think there are too many Makefile generators out there… some of the parallel ones are particularly interesting, but CMake has become [basically] the standard. It also does all sorts of nice packaging (cpack) and testing (ctest).
@clsource If you want to work on a replacement packager… I'm keen 📦
And the popularity contest begin...
The idea of having a generator in wren is very nice, to make it more autonomous, I don't think it wise to do so because of the chicken egg problem, and would force to provide pre-generated makefiles and/or wren binaries for the shell or a dedicated tool.
and would force to provide pre-generated makefiles
Like we already do you mean? ;-)
and/or wren binaries for the shell or a dedicated tool.
This isn't a super hard problem though. I have a GitHub action that builds the CLI for every platform automatically and makes it available for download...
This isn't replacing premake/make with cmake, nor would I want to do that. This is just adding the CMake definition file so you can use cmake to both build and embed wren from other applications that use cmake. I'd love for premake to have cmake support out-of-the-box so we can regenerate it easily, but alas, no. Given that, however, the CMake definition file is pretty simple, so I'm more than happy to help keep it up to date for any changes.
btw I am currently setting up a conda-forge build for wren. (I need wren on conda-forge since I want to put wren based jupyter kernel on conda https://github.com/DerThorsten/xeus-wren) I tried quite a bit with the provided build systems, but for win I could not make it work. Therefore I added a CMakeLists.txt in the conda-forge recipe (which is a bit unorthodox) https://github.com/conda-forge/staged-recipes/pull/16201
I think adding a cmake project makes a lot of sense. As @RobLoach mentioned people usually just want to do add_subdirectory on a CMake directory these days and have the target available for their project.
At our workplace we have like 20 C/C++ dependencies and it works for 95% of them.
This would probably also make the Visual Studio project files obsolet, since VS supports CMake out of the box (it can open a project from a CMakeLists.txt)
Anywhere where I use wren, I basically have to provide a custom CMake build system since wren does not ship one.
https://github.com/conda-forge/wren-feedstock/blob/master/recipe/CMakeLists.txt https://github.com/DerThorsten/jupyterlite_xeus_wren/blob/main/CMakeLists.txt
Not having a CMakelist in a project like this feels like a defect