[HN Gopher] Chalet: A cross-platform project format and build to...
___________________________________________________________________
Chalet: A cross-platform project format and build tool for C/C++
Author : rewrking
Score : 62 points
Date : 2022-06-10 10:40 UTC (12 hours ago)
(HTM) web link (www.chalet-work.space)
(TXT) w3m dump (www.chalet-work.space)
| MafellUser wrote:
| 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.
| natpalmer1776 wrote:
| 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.
| pornel wrote:
| 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.
| rewrking wrote:
| I think an opinionated project layout (like Pitchfork) makes
| the most sense for packages. It would be nice to go in that
| direction one day.
| sebastos wrote:
| 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.
| srydell wrote:
| Sounds like a cool project. Well done!
| jb1991 wrote:
| I do something similar to this with just a couple simple bash
| scripts that allow me a similar interface to this one... because
| it is indeed useful.
| rtorr wrote:
| A tool like this is so needed in this space. Looks great. I see
| the integration docs, but how does it currently work with visual
| studio (not code)?
| rewrking wrote:
| 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.
| rstat1 wrote:
| I've wanted to make something like this for a while. Starting a
| new C++ project for me has gotten to be very tedious.
| jb1991 wrote:
| Shouldn't this be prefaced with "Show HN:" ?
| rewrking wrote:
| Looks like it. Sorry about that -- new to HN.
| rewrking wrote:
| https://github.com/chalet-org/chalet - primary repository
|
| 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.
| rtorr wrote:
| Looks amazing!
| fouronnes3 wrote:
| 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.
| rewrking wrote:
| Couldn't agree more! Glad there are others that feel this way.
| synergy20 wrote:
| true, c++ renews itself every 3 years which is great, except
| that its tooling remains the same.
|
| equip c++ with new tooling like what golang and rust have will
| be a huge boost to this language.
| dasloop wrote:
| 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) ;)
| TillE wrote:
| 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).
| MafellUser wrote:
| OTOH learning how to debug cmake will guarantee your
| employment for life so there's an incentive.
| dasloop wrote:
| ExternalProject_Add -> vcpkg or Conan. I have more
| experience with vcpkg and the steps are:
|
| 1) declare your dependencies in a vcpkg.json file
| (similar to npm's package.json). Example:
|
| { ... "dependencies": [ "openssl" ] }
|
| 2) Add it to your CMakeLists.txt file. Example:
| find_package(OpenSSL REQUIRED)
| target_link_libraries(main PRIVATE OpenSSL::SSL
| OpenSSL::Crypto)
___________________________________________________________________
(page generated 2022-06-10 23:02 UTC)