This is a project of mine that has been in the works for a little over a year and a half. The main goal of Chalet is ultimately to streamline C/C++ tooling as much as possible. In practice it's a command-line application for its own project format, much like msbuild or xcodebuild, that can take C/C++ code from various sources and build them using the same compiler toolchain. It can also run your executable applications after the build and handle paths for you. Chalet can also fetch git repositories by branch, tag or commit. It also supports cross-compiling without reconfiguring, and just requires a couple different options at the command-line.
This is the first release, and right now it works with all major compilers. The downside is that there isn't much in the way of IDE integration yet aside from a VS Code extension. This will hopefully change in the future as the application matures and interest grows. VS Code, text editors, and anything that execute command line applications are perfectly suitable otherwise.
The rest of the features and details are explained on the website, but it's worth noting that building C++20 modules with MSVC is also supported.
The docs might be spotty in places, so any feedback is appreciated. I hope this is something others are interested in, and can try out with some of their projects.
It's nice that it tries to have an abstraction layer over compiler flags. Too many build tools are a mere indirection, not abstraction over underlying tools, and require each build script to deal with every compiler's flags the hard way (especially painful for MSVC vs gcc-alikes).
I wish this went further to have an opinion on project layout, like location of source files and include dirs. Every C/C++ build system I've seen has a configuration-over-convention approach rather than the other way around. I get it's by necessity to accommodate arbitrary pre-existing projects, but it's unfortunate that it perpetuates C projects being snowflakes, each with a slightly different directory structure, approach to includes, naming scheme of defines, different ways of enabling optional features, different way of running tests, and so on. Because of that maximal flexibility even projects using the same build system end up being gratuitously different.
I can definitely second that making use of sane default project structure to reduce even more boilerplate would be an extremely attractive feature. Reducing some of the incomprehensibly large amount of incidentally complex C++ project builds would practically qualify as humanitarian aid at this point.
I just want to say I really appreciate seeing tooling like this.
Having tried to get into C/C++ development roughly 3-4 years ago, I found the toolchain associated with getting even basic projects working incredibly complex and opaque as someone without industry experience.
From a brief look over the documentation of this project, I feel like I could get something up and running in very little time.
Best of luck with this project. Tooling is probably the hardest to migrate since literally everything depends on it and you can't really it parts by parts, also it is the classic if it doesn't break don't fix it.
Would be amazing if there's a script to quickly convert common mk files and cmake files into chalet format, that would absolutely help with adoption amongst legacy codebases.
Looks very nice. C++ is seriously behind in terms of tooling so any project in this space is most welcome. Of course we are entering the xkcd 927 stage now and the only thing even remotely close to being a defacto standard is CMake. What we really need is the committee to start aggressively prioritizing on useful stuff like tooling, build system, modules, packages and bug fixes - and less on esoteric language features that just make the language more complex.
With the exception of CMake evolution (now days a defacto standard), package managers (as Conan or vcpkg) or the support for new C++ standards in major compilers (clang, gcc, Visual) ;)
It's good that the C++ world has effectively standardized on something, but CMake still has a steep learning curve. I hate its structure as a jumbled mess of independent commands.
It needs more guidance for making simple, typical projects easy to set up, at the very least more stuff that works like ExternalProject_Add (a big powerful command with all its options clearly documented on one page).
No great solution yet. I didn't have the mental bandwidth to add either a VS project export or a VS extension for this release, but they're planned. Currently, you'd have to create a tasks.vs.json file and launch.vs.json to build the project in Visual Studio. It should build the same way it does outside of VS.
https://github.com/chalet-org - github org w/ example projects
This is a project of mine that has been in the works for a little over a year and a half. The main goal of Chalet is ultimately to streamline C/C++ tooling as much as possible. In practice it's a command-line application for its own project format, much like msbuild or xcodebuild, that can take C/C++ code from various sources and build them using the same compiler toolchain. It can also run your executable applications after the build and handle paths for you. Chalet can also fetch git repositories by branch, tag or commit. It also supports cross-compiling without reconfiguring, and just requires a couple different options at the command-line.
This is the first release, and right now it works with all major compilers. The downside is that there isn't much in the way of IDE integration yet aside from a VS Code extension. This will hopefully change in the future as the application matures and interest grows. VS Code, text editors, and anything that execute command line applications are perfectly suitable otherwise.
The rest of the features and details are explained on the website, but it's worth noting that building C++20 modules with MSVC is also supported.
The docs might be spotty in places, so any feedback is appreciated. I hope this is something others are interested in, and can try out with some of their projects.