Cmake is inside-out

[alerque]

Something is setup quite un-orthodox about CMake. CMake strongly encourages out of source builds using a build directory and suggests the name 'build', but this is supposed to be an empty directory provided by the user (at least the name needs to be provided, cmake actually creates it if used in the -B ... argument). A 'build' directory should not part of the project source. The CMake configuration should be promoted to the top level in the source here. Cmake modules and other helper scripts can be squirreled away somewhere else in the source, but the 'build' directory is the wrong place for them (since that is CMake's suggested location to build).

[pkulchenko]

I agree that it's not ideal, but I'm reluctant to change this configuration. The build/ folder already existed when CMakeLists.txt was added and I didn't want to create yet another folder just to host CMake-related files (and build/ folder looked like the best place anyway); I would certainly oppose to moving CMake files to the top of the source tree. I'd consider adding a shell script in the build folder that would set up everything needed to facilitate CMake builds, but keep in mind that this was added as a convenience for a subset of Linux targets (similar to Arch), as everything else is built using (other) scripts provided in the build/ folder.

[alerque]

It's not just cmake, the whole project is inside out! You've got the source repository being a portable binary distribution and are trying to hack on building the source & a companion install onto that bundle. The repository should the the source, building it should generate the necessary binaries (with an optional install step), and an optional build routine should build a "portable binary bundle" for those that wish it.

[pkulchenko]

The repository should the the source, building it should generate the necessary binaries (with an optional install step), and an optional build routine should build a "portable binary bundle" for those that wish it.

I agree with this in a vast majority of cases, but more than half of ZBS users are on Windows and not having binaries to run the IDE puts the strain on them to have compilers available and configurable and on me to support VS, clang, and mingw/tdm-gcc in addition to the setup that I use. It takes time to download and build wxwidgets, wxlua and all dependencies, so you'd have to wait likely an hour before being able to run the project.

I realize the downsides of keeping the binaries in the repo and have been considering multigit to alleviate some of the pain (and possibly avoid storing new versions of binaries in the source repo), but I don't have short-term plans to change the approach, as it's been working quite well for the project, despite being unorthodox.

[bassklampfe]

@pkulchenko : I really like - although it is not "the normal way" - the concept of getting a ready to use package right after the clone. I can switch between different tags or branches without having to uninstall, redownload, reinstall. So please keep it just the way it is. JM2C :+1: And I'm a linux user :smile:

[pkulchenko]

Thanks @bassklampfe for the feedback! It's actually a good point on branch and tag switching, as it's a constant pain for me to bisect changes in wxwidgets, as every step requires re-compilation and re-install of dependencies, so even 10 steps can easily take a day to accomplish. I don't do frequent binary updates, but there are still dependencies between the Lua code and the binaries, so having them both available definitely simplifies the process.