Fix/Clean the build directory
Flamefire opened this issue · comments
I think the whole build folder can be removed. This would make it easier to work with during development as "build" is often used as the default folder for generated build files. But it might make sense to actually clean it up a bit.
@mat007 Could you check what build files are actually required?
- The VC project files can surely go, CMake creates them and they are (likely) outdated anyway. Done that in my PR but can extract
- What are the build.xml and build.properties files? Is that some other IDE? Are those still correct and/or required or can they be removed? I'd suggest to only use CMake and let that create the files for whatever IDE you'd like to use. Happy to help here if required, but I think the current CMake build system is pretty complete already
- The Dockerfiles might be nice, but I guess those packages could just be mentioned in the Readme. If you'd really like to keep them, maybe put them in another folder. (e.g. "scripts", see below)
- The build.[sh,bat] might be better suited for a "scripts" folder
- The version.hpp is a good idea. This can be moved to the root as version.hpp.cmake and configured by CMake and added to the install procedure.
I agree with removing everything.
The only bits I’d like to keep are the Dockerfiles as they’re quite convenient and the only way for me at the moment to actually build and run tests. They could be enhanced though to cover creating the release packages as it’s a manual process at the moment.
To remind me how to do a release I was even keeping the build.xml file around, which is so outdated that I don’t even have access anymore to the build system it was relying on 😬.
I think we can probably drop the whole conversion to a Boost.Mock library as well…
The only bits I’d like to keep are the Dockerfiles as they’re quite convenient and the only way for me at the moment to actually build and run tests.
Why doesn't cd build && cmake -DCMAKE_BUILD_TYPE=Debug .. && make && make test work for you? All it needs is a compiler and a suitable Boost installation which isn't much.
They could be enhanced though to cover creating the release packages as it’s a manual process at the moment.
What exactly do you mean by "release packages"? Is this https://github.com/mat007/turtle/releases/download/v1.3.2/turtle-1.3.2.tar.gz ? If so may I suggest to just create a docs package instead and leave the default github download https://github.com/mat007/turtle/archive/v1.3.2.tar.gz for everything else? This can even be automated by github actions.
I've been working with EasyBuild (an installation framework) and it uses those archives, prefers to have the build system included (CMake here) and likes to run tests if possible. I mean in the end users can simply wget the file above, extract it and install with cmake. This way even find_package(turtle) will work which is a good thing. Or just copy the include folder out of it.
I think we can probably drop the whole conversion to a Boost.Mock library as well…
Where is this happening? Only mentions to Boost.Mock are in 2 comments and index.html.
But we might do a v2 release next which consistently uses TURTLE_ as the prefix for macros instead of MOCK_ to follow conventions. On the other hand: MOCK_ is just to good to be changed... Maybe just keep it for user-facing macros.
Why doesn't cd build && cmake -DCMAKE_BUILD_TYPE=Debug .. && make && make test work for you? All it needs is a compiler and a suitable Boost installation which isn't much.
Because I don’t have a C++ compiler installed and I’m very much into keeping my system lean these days. Also it’s my company (Windows) laptop and I don’t have a personal one…
Anyway I don’t really mind, I’ll just create an image that does everything and push it to a Docker Hub repository for me to use whenever I need it.
If you’d rather we delete these files, that’s fine by me!
What exactly do you mean by "release packages"? Is this https://github.com/mat007/turtle/releases/download/v1.3.2/turtle-1.3.2.tar.gz ?
Yes.
If so may I suggest to just create a docs package instead and leave the default github download https://github.com/mat007/turtle/archive/v1.3.2.tar.gz for everything else? This can even be automated by github actions.
Yeah the default github release archives probably do the job.
An action to build and deploy the docs is quite a nice suggestion!
Where is this happening? Only mentions to Boost.Mock are in 2 comments and index.html.
In build.xml, but it hasn’t been used in years and I don’t think anyone cares about it otherwise they would have complained 😬
Checkout https://github.com/Flamefire/turtle/blob/master/.github/workflows/release.yml which creates https://github.com/Flamefire/turtle/releases/tag/v0.0.1
It runs the doc creation on each push but publishes only on tags, so you can double check before pushing a tag. It will also create a draft with the docs, which you can then manually publish