[HN Gopher] A new CMake Scripting Language?
___________________________________________________________________
A new CMake Scripting Language?
Author : gumby
Score : 58 points
Date : 2022-12-05 13:59 UTC (1 days ago)
(HTM) web link (zenodo.org)
(TXT) w3m dump (zenodo.org)
| Kukumber wrote:
| CMake needs to go
|
| There are much better alternatives:
|
| https://xmake.io/
| Kukumber wrote:
| downvoted, i mean what did i expect on a discussion about the
| idea to add a scripting language on top of a scripting language
| that is used to generate a script in an other scripting
| language
|
| c++ is doomed
| Koshkin wrote:
| No, C was Doomed, C++ is Unrealed.
| travisgriggs wrote:
| make, automake, conf, autoconf, m4 ...
|
| I don't understand why people are surprised to see similar
| complexity creep in the "reborn" CMake ecosystem.
|
| There has never been a one size fits all all purpose glue. It's
| not surprising to me that neither is it possible to make a one
| size fits all "glue my software together" stack.
| arberx wrote:
| Please, god, not another CMake "improvement"...
| dale_glass wrote:
| Why, is having it still suck going to be better?
|
| Plus the idea seems to be to add it on top, so if it flops, no
| big deal, the old stuff will still be there.
| qznc wrote:
| It is a big deal for people who have to maintain the build
| systems which contain both languages.
| dale_glass wrote:
| That doesn't seem like a huge deal. Most projects would
| have some sort of internal discussion about whether to
| adopt this or not. It's not going to show up out of
| nowhere.
| planede wrote:
| My recent gripe with CMake: the language toolchain is still a
| singleton. You can't easily use multiple C++ compilers in the
| same build. This doesn't feel like a language limitation.
|
| I also never got why we need DSLs for build systems. It seems
| like Turing completeness is often inevitable, no matter if people
| don't like it. There is no reason that a build file couldn't be
| mostly declarative with a general-purpose programming language
| though.
| matthews2 wrote:
| > the language toolchain is still a singleton. You can't easily
| use multiple C++ compilers in the same build. This doesn't feel
| like a language limitation
|
| If you're still struggling with this, a solution is to use
| ExternalProject to create a "superbuild" top level project that
| has various subprojects being built with different toolchains.
| mdaniel wrote:
| > I also never got why we need DSLs for build systems
|
| The same reason they show up anywhere: to have the correct
| level of abstraction, or its cousin "signal/noise ratio."
| Trying to debug "gcc -o build build.cc && ./build" sounds like
| the 8th circle of hell to me. I can show a concrete example:
| https://github.com/facebook/sapling/blob/0.1.20221201-095354...
| So, when this raises OSError or FileNotFoundError due to some
| botched assumption, I guess one just attaches pdb to it and now
| your job is to be a python expert
|
| Or, my other favorite "what is wrong with you:"
| https://hg.mozilla.org/mozilla-central/file/FIREFOX_NIGHTLY_...
|
| Or, so as to not just be hating on python, this junk:
| https://github.com/brave/brave-browser/blob/v1.48.33/package...
| and its https://github.com/brave/brave-
| core/blob/master/build/comman... friend
|
| All of those are in a general purpose programming language, and
| they require spelunking through _thousands_ of lines of code to
| surface the actual commands and dependencies that are buried
| therein. And, if you become a domain expert in mach, where else
| are you going to apply that expertise?
| jhoechtl wrote:
| I recently had the need to propose a build tool. Naturally make
| came to my mind then I looked into something more modern. I
| didn't dive deep but I was left with impression that CMake and
| many others support a certain set of programming languages?
|
| PS: I know that make has many shortcuts to compile a C/C++
| codebase but in essence its targets as file system time stamps.
| duped wrote:
| This article is discussing the scripting language of CMake (the
| code that describes the build) not the program that it builds.
|
| But to your question, the answer is kinda. There is support for
| a few other languages built in (off the top of my head, Ada and
| Fortran I believe) and you can provide a custom backend as well
| for your own language support but most people just use
| add_external_command
| bdavis__ wrote:
| fortran works fine. it has a compilation model very similar
| to C. (Note this comment is based upon F77 / F90. Fortran
| modules may be different).
|
| ada support in cmake is terrible. in the end you have to call
| gnatmake several times, if you want a build that always work.
| terrible.
| bmh wrote:
| It's conceivable that within a year or two, Copilot will be good
| enough to make the pain of the CMake language much more bearable.
| actionfromafar wrote:
| A prime specimen for "impossible to tell if sarcasm".
| chrsig wrote:
| A year or two might be enough for the c++ community to
| sufficiently complect the build process enough to befuddle any
| AI
| an1sotropy wrote:
| The slide deck seems like a pitch for more funding to create a
| CMake replacement, rather than a description of that replacement,
| right? It ends with "A $1M+ investment in a new CMake language(s)
| and translation tools could avoid a future massively expensive
| transition of ASC [Advanced Simulation and Computing, at Sandia
| National labes] codes to another tool like Meson that could
| easily cost more than $10M across the ASC program and negatively
| impact developer productivity while the transition is taking
| place."
|
| I'm curious: is there any way to estimate how much US taxpayer
| support went into creating CMake? Would CMake exist were it not
| for the DOE and/or NSF grants that Kitware got?
|
| Getting that kind of support isn't a fault of CMake, but I think
| it's a meaningful property in considering and comparing different
| software development projects, and evaluating their long-term
| health.
| marwis wrote:
| I find it a bit disingenuous how they don't include costs of
| transition to this new CMake++ in their comparison to Meson
| migration.
| samlittlewood wrote:
| Please no! People will start hanging around trying to do clever
| programmer stuff, and then we will be in all sorts of trouble.
| flaviut wrote:
| It's already bad enough that the developer needs to understand
| both target-based CMake and legacy CMake, now there need to be
| two more languages (slide 13) that must be understood? It's been
| 9 years since Modern CMake came out, and I'd estimate adoption at
| 50-50.
|
| This deck does not address the drawbacks of doing this at all,
| and the only recognition of this problem is in "Stretch Goal:
| Research development of tool(s) to translate legacy CMake to new
| CMake language."
|
| The current CMake language is fine. Nothing amazing, but good
| enough.
|
| But every moment that I spend configuring CMake is a moment I
| don't spend doing something actually useful. I don't want to
| disparage the team's work--CMake is awesome software--but the way
| they see it is very different from the way typical developers see
| it.
| throwaway894345 wrote:
| > The current CMake language is fine. Nothing amazing, but good
| enough.
|
| Lol CMake was a huge reason I got out of C++ development almost
| a decade ago. I was tired of scripting my own shitty build
| systems, especially ones which couldn't even manage packages. I
| never actually need the power CMake offers, but the stuff I do
| need (reproducible package management) CMake punted on. 99.9%
| of the time, all you need is a build tool that takes a list of
| dependencies and a lockfile (or similar).
| cogman10 wrote:
| It's really quiet glorious how absurdly complicated the C++
| development environment is. Want to build something? Well,
| you'll need a c compiler. Want multiple files in it? Well,
| you'll need a Makefile. Want a dependency? Well, now you have
| to decide if you want cmake, autotools, bazel, scons, meson,
| ninja, or to write your own bash script? Why? Who knows! Oh,
| does that install the dependency for you? No, don't be silly,
| those tools simply determine what your current platform has.
| 5e92cb50239222b wrote:
| > does that install the dependency for you
|
| https://mesonbuild.com/Wrapdb-projects.html
|
| Writing new wraps involves essentially porting the target
| project to meson though, so it's far from trivial.
| throwaway894345 wrote:
| Yeah, and the real tragedy is that these are all solved
| problems in other ecosystems. The C++ folks often don't
| know what they're missing out on. Which is too bad, because
| while C++-the-language gets a lot of flack, modern C++ is
| actually pretty cool (still a bit of a bear to figure out
| which features _not_ to use). But the tooling is just
| insanely cumbersome (it 's been a while since I've
| developed C++, but last I checked even getting decent
| editor support was absurdly hard and the various Vim/etc
| plugins that promised said support never worked out of the
| box).
| jcelerier wrote:
| > 99.9% of the time, all you need is a build tool that takes
| a list of dependencies and a lockfile (or similar).
|
| I'm very happy for you but almost all the C++ projects I've
| worked on have needed muuuuuuch more complex build system
| scripting than this.
| cogman10 wrote:
| The question you should be asking yourself is "why? why
| does my C++ project need 18 programming languages to build
| and java needs an xml file, javascript some json, or rust a
| toml file".
| throwaway894345 wrote:
| In fairness, many of the CMake criticisms also apply to
| Gradle in the Java world, but yeah, Go just needs its
| go.mod file, Rust just needs its Cargo.toml file.
| tannhaeuser wrote:
| > _java needs an xml file_
|
| But that was too boring, so people turned to gradle and
| we're back at ad-hoc scripting in a bizarre Turing-
| complete language. Believe me, I've hated maven with a
| passion (and still do) but this episode taught me build
| systems are nothing but a zero-sum game and typical
| junior-grade pastime.
|
| Update: the story with Node.js is a bit different, but
| package.json was soon augmented by package-lock.json and
| yarn at about the same time Webpack and similar became
| kitchen sinks requiring config-generator tools such as
| create-react-app. The morale is, the grass is always
| greener on the other side I guess. Though tbh, cmake
| always was absolute garbage making autotools look sane in
| comparison. Now I hear there's legacy/unmaintained and
| new cmake syntax; what were people thinking?
| throwaway894345 wrote:
| This is a straw man. The objection was never "XML is too
| boring", the objection was "the XML models an actual
| programming language, so we're doing imperative
| programming but without the ergonomics and syntax of a
| programming language". "It's just XML/YAML/HCL! Way
| easier than programming in an imperative language!" is
| such a farce (not only among build systems but especially
| among infrastructure-as-code solutions).
|
| Just because it accepts XML doesn't mean your build
| system is _meaningfully_ declarative.
| tannhaeuser wrote:
| Oh, I fully agree with your argument as it applies to the
| old ant build tool, which is in fact a programming
| language using XML serialization - the author even
| apologized for it when he realized syntax wasn't the hard
| part. But a maven pom.xml is actually a component model
| serialization rather than a programming language in
| disguise - unless you're referring to embedded ant
| scripts in maven files which _is_ a thing, but not common
| enough to warrant criticism IMO. Scripted deployment
| tasks in a Java context were more commonly seen in
| Jenkins, and only recently spill into gradle build
| scripts (I 've always thought gradle was following
| Jenkins' Groovy syntax for eventual integration but that
| hasn't happened).
| jcelerier wrote:
| how many times did you have to build a java or javascript
| project where you are counting _kilobytes_ , or are pre-
| generating data tables for maximum efficiency which you
| want to be configurable as a build option because you're
| going to need different tables for different
| hardware/target ? people with this sort of problem just
| aren't even considering using java or javascript so of
| course in C++ we end up with a hairier solution. A lot
| could be solved if there was good compile-time reflection
| for sure but still.
|
| An example: the main software I work on, along with a few
| other software I know, has to generate a SDK as part of
| its build so that people can build plug-ins for it. How
| often do you have to do this in java or JS ? almost
| never. But this requirement implies having a build system
| powerful enough to do that.
|
| Another example: another software I work on must produce
| a Max/MSP package ; this implies:
|
| - working with multiple versions of the Max SDK which
| changed their structure on disk
|
| - setting different build options such as file naming
| depending on the target architecture: .dll on win32,
| .dll64 on win64
|
| - generating a relatively complex tree structure which
| combines a Windows and a macOS build together because
| people don't want the hassle of having two different
| download options
|
| - generating some stub C file that will declare a
| function to be exported
|
| - generating some .json file with various build
| information, build date, etc
|
| - generating a symbols.txt file which contains all the
| symbols that are known to be explicitly exported to
| minimize binary size ; the build system has to: list the
| symbols (one per plug-in we build), write them to a
| symbols.txt file, pass that file to Apple's dyld like
| this: set_property(TARGET ossia-max
| APPEND PROPERTY LINK_FLAGS "-s
| -exported_symbols_list
| '${CMAKE_CURRENT_BINARY_DIR}/symbols.txt'" )
|
| etc etc.
|
| these are the _requirements_ we have. can you solve these
| requirements with just Java 's XML ?
| throwaway894345 wrote:
| I mean, my remark was a bit of an oversimplification.
| Modern build systems do a bit more than take a list of
| dependencies--they'll also allow for bundling data files
| into the compiled artifact, platform-conditional
| compilation units, and a few other things. But they don't
| expose these things as a fully imperative scripting
| language / meta build system--a few bits of declarative
| configuration can cover 99.9% of use cases.
| mort96 wrote:
| The absolutely atrocious current cmake language (where you
| can't even make a list of strings! The ONE THING a make
| replacement should fix!), in combination with the prevalence of
| legacy cmake everywhere (even in Find*.cmake files distributed
| by cmake!), are the two primary reasons why I'm using and
| rooting for Meson over CMake.
|
| But its biggest issue, arguably, is the extreme proliferation
| of bad information. Everything on StackOverflow and similar
| sites is outdated and bad practice for the most part. You're
| right that introducing a new language which deprecates the old
| will make this an even bigger issue.
| simplotek wrote:
| > It's already bad enough that the developer needs to
| understand both target-based CMake and legacy CMake (...)
|
| No. "Legacy cmake" has been made obsolete with the release of
| cmake 3.0, almost a decade ago. There is absolutely no excuse
| to use anything other than the declarative, target-based
| "modern cmake" style.
|
| I'd go as far as claiming that 95% of all use cases boil down
| to simple straight-forward one-liners with modern cmake, with
| the remaining 5% corresponding to putting together custom cmake
| find modules, packaging, and deploying runtime dependencies.
|
| > (...) now there need to be two more languages (slide 13)
| (...)
|
| I'd argue that if anyone feels the need to write scripts to do
| something in cmake, they are already doing something awfully
| wrong to start with.
| chrsig wrote:
| > No. "Legacy cmake" has been made obsolete with the release
| of cmake 3.0, almost a decade ago. There is absolutely no
| excuse to use anything other than the declarative, target-
| based "modern cmake" style.
|
| "made obsolete" != expunged from codebases. I'm sure there
| are plenty using cmake 2.x conventions that haven't been
| updated, and need maintaining. And in order to either
| maintain or upgrade, one needs to know both conventions.
| simplotek wrote:
| > And in order to either maintain or upgrade, one needs to
| know both conventions.
|
| No, not really. You only need to know the declarative,
| target-based modern cmake. Most of the ad-hoc nonsense done
| with legacy cmake is either features that since the 2.x
| days were added to cmake, or nonsense that should never
| have been written to start with.
| kjs3 wrote:
| What a fascinating planet you must live on where legacy
| doesn't exist, or if it does developers can see into the
| future and know what will be 'nonsense' in 10 years time,
| or make the whole thing moot because of course they
| rewrite their build framework for every release of the
| build system, having unlimited resources at hand. Must be
| nice there.
| tannhaeuser wrote:
| Apart from what sibling commenters say, the problem is
| that cmake's original syntax was introduced with the same
| glowing fanatism (over plain old Makefiles) that's now on
| display with cmake 3.0 (or is it 2.0?) over "old" cmake,
| making this enthusiasm not quite justifiable.
|
| If your old lib can't be build due to a deprecated build
| system, that's already the greatest possible disaster for
| a build system, as all your automatic tests etc might not
| run anymore and you lack a basis for releasing anything
| at that point. You need to setup an entire new project
| for recovery.
| bdavis__ wrote:
| But you still have to deal with it. It exists!!
| chrsig wrote:
| You're missing the point -- it _was_ written and still
| exists, and still needs to either be maintained or re-
| written. You can 't do either of those things if you
| don't understand it.
| liquidify wrote:
| Cmake is terrible to use.
| StreamBright wrote:
| I just don't get the hype around make/CMake/autotools. I
| usually implement the build tool in the language I am working
| on (build.py for Python, etc.). It seems that Zig[1] also
| follows this.
|
| What am I missing?
|
| 1. https://ziglearn.org/chapter-3/
| UncleEntity wrote:
| > What am I missing?
|
| C/C++ compilers don't have a scripting language built in to
| construct your build system on top of?
|
| I mostly use distools to build python modules but I have a
| couple projects where there is code generation, building
| static libs, &etc... and I find it easier to use cmake to
| just pop out a python module.
|
| Cmake can also be convinced to make distro packages, like
| rpms and debs, without too much trouble -- not sure how to do
| that in any other build system.
| Koshkin wrote:
| This is the sanest idea of all, it seems. C++ could easily
| have a library of build and dependency-tracking classes with
| a sensible API. Then you could use anything you want in your
| build "script" that C++ has to offer and not have to jump
| through hoops to accommodate the most complicated use cases.
| (And no, you would not be needing a build script for your
| build tool.)
| Izkata wrote:
| I don't know about the other two, but the recent resurgence
| of "make" seems to be around using it as a standard interface
| for running tasks. For example, "make build" would run
| build.py in a python project, webpack in a javascript
| project, etc.
|
| Similarly there's things that have been ad-hoc standards
| forever, like "make clean" to remove all build and test
| artifacts, or "make test" for running tests.
|
| Many of my coworkers only use it in this way and are unaware
| make looks at files/timestamps.
| catiopatio wrote:
| > What am I missing?
|
| The irony of using "hype" to describe make/CMake/autotools
| while referencing _Zig_ as an alternative example.
|
| Building a build tool written in C or C++ requires a build
| tool -- hence the existence of make/CMake/autotools, which
| can bootstrap themselves from a minimal environment.
| StreamBright wrote:
| If I was referencing Zig az the __only__ alternative I
| would agree. What I wanted to say is to use the same
| language / tool that your projects uses. Maybe it is
| impossible for C/C++ as some comments pointed out.
| chrsig wrote:
| > It's been 9 years since Modern CMake came out, and I'd
| estimate adoption at 50-50.
|
| > The current CMake language is fine. Nothing amazing, but good
| enough.
|
| I'd argue these two statements are in conflict.
|
| I came to c/c++ after several other languages and ecosystems --
| the c++ dependency/build ecosystem is by far the worst.
|
| CMake does work. It's underlying capabilities are great, even.
| But "modern cmake" is sort of a joke syntactically. Generator
| expressions are indecipherable. Semicolon delimited arrays, no
| distinguishing between input/output variables... I personally
| would _love_ for a different DSL frontend to CMake.
|
| > I don't want to disparage the team's work--CMake is awesome
| software--but the way they see it is very different from the
| way typical developers see it.
|
| I have to agree with this. The underlying core of cmake is
| actually pretty awesome. Modern cmake _is_ an improvement in
| capability. The team deserves credit for that.
| TillE wrote:
| > But "modern cmake" is sort of a joke syntactically.
| Generator expressions are indecipherable.
|
| Yeah. CMake works, it _can_ do everything you want _somehow_
| , but it's a total mess, and the documentation isn't great.
|
| Just a simple wrapper API (like libcurl-easy, for example)
| would go a long way.
| tsss wrote:
| > CMake is awesome software
|
| No, CMake is terrible. It is in fact quite a feat how god damn
| terrible it manages to be.
| ghoward wrote:
| Disclaimer: author of a build system that will compete against
| CMake when it's released.
|
| I'm not impressed, for two reasons:
|
| * Backwards compatibility for the CMake language is _not_
| desirable. It would be better to allow files to be translated to
| the new language completely. Sure, CMake could support having
| files in the old language and files in the new language, but the
| CMake language is so bad that a break from it is the best path
| forward.
|
| * The CMake language is _not_ the only drawback to CMake, unlike
| the claims in the presentation. CMake 's model is hamstrung as
| well, in several ways.
|
| Here are some ways in which the CMake model is hamstrung:
|
| * Generating a build file for another build system. This means
| that CMake always gives up control of the build. It can only tell
| the other build system the dependency graph and then sit back and
| watch. It can't regulate the build itself.
|
| * No dynamic dependencies. If you need dynamic dependencies, you
| need to call into CMake to generate a _new_ and _separate_ build
| file for the second build system and then call that. And because
| the two build files that CMake generated don 't know anything
| about each other, it's hard to regulate the use of computing
| resources between them; you either have to complete the one and
| start the other, or you risk over-extending on your computing
| resources.
|
| * No way to generate a target that doesn't call an outside
| process. More generally, the only way to generate a target
| (unless my CMake knowledge is old) is to have the second build
| system create a child process. This is strictly less powerful
| than having the same scripting language available during
| configure also available in targets. For example, LaTeX is only
| properly built with a loop that checks for a fixed point. If you
| can't loop in your target, you have to use an outside bash script
| or something of the sort to make up for it.
|
| * No way to have targets that do not generate files and have
| other targets depend on those targets. If a target does not
| generate a file, CMake does not know how to make other targets
| depend on it (unless my CMake knowledge is old).
|
| * The model of "configure in Turing complete language and then
| build" also means that configuring often has to happen more than
| once before a build. You see this if you use `ccmake`: you
| configure, and new options appear. You set the options and
| configure again. More options might appear. Using plain `cmake`
| hides this by using defaults, but that just means the user might
| end up with a build they didn't want because they didn't get a
| chance to set all of the options they might care about.
|
| Anyway, rant over.
| substation13 wrote:
| Are you a solo dev? I wonder how much can be done compared to
| the teams behind Bazel and Buck(2)
|
| Anyway, CMake is terrible - for all the reasons you have
| identified - so I wish you luck!
| ghoward wrote:
| Yes, I'm a solo dev and not looking for contributors. My
| style is too eccentric to accept outside contributions.
|
| Funny you should mention Bazel and Buck; I'm coming for them
| too! I'm also coming for Nix; I want its advantages to be
| easily accessible for mere mortals.
|
| I think I can do better alone than those teams have because
| they have all made assumptions that weren't great. I'm
| learning from their mistakes.
|
| Also, UX matters, and I'm putting a lot of effort into that.
|
| But the other reason is that if you do Nix right, the
| capabilities of Bazel and Buck just appear.
|
| Thank you for the encouragement!
| dlivingston wrote:
| > Here are some ways in which the CMake model is hamstrung...
| generating a build file for another build system
|
| That's the critical selling point of CMake in my estimation.
| When I'm on Windows, I can generate a Visual Studio project and
| use its excellent debugger and code analysis tools. When I'm on
| Mac, I can generate an XCode project. Or a CLion project, or
| Makefiles, or...
|
| Decoupling the build "recipe" from the build toolchain is
| critical for collaborative, cross-platform, cross-architecture
| projects, IMHO.
|
| > No way to have targets that do not generate files and have
| other targets depend on those targets.
|
| Isn't that exactly what an INTERFACE library is for? <https://c
| make.org/cmake/help/latest/command/add_library.html...>
| Koshkin wrote:
| > _I can generate a Visual Studio project_
|
| Except that you don't need to, Visual Studio has support for
| CMake built in (since 2017).
| ghoward wrote:
| > That's the critical selling point of CMake in my
| estimation. When I'm on Windows, I can generate a Visual
| Studio project and use its excellent debugger and code
| analysis tools. When I'm on Mac, I can generate an XCode
| project. Or a CLion project, or Makefiles, or...
|
| I've already addressed some of this in another comment ([1]),
| but you bring up more points, so I'll address it here.
|
| CMake's model _forces_ it to generate build files for other
| build systems. The better model does not force the build
| system to, but it also _does not preclude doing so_.
|
| Separately from actually running a build (and that's
| important), my build system will be capable of generating
| files for VS, XCode, and other IDE's, but the files it
| generates will simply tell the IDE's how to integrate with my
| build system by telling them how to call it with the correct
| build profile. And yes, it will generate multiple possible
| build profiles, allowing VS users to select the solution the
| want to build from within VS.
|
| But this means that my build system will not only integrate
| better with IDE's than CMake, it will still retain full
| control of actual builds.
|
| This includes using debuggers and analysis tools, by the way.
| I wouldn't consider my work done on IDE integration until all
| of that is as easy as possible, and definitely as easy as
| CMake.
|
| > Isn't that exactly what an INTERFACE library is for?
|
| Maybe? It might be enough. At first glance (and I fully
| acknowledge that I could be wrong here), it seems like CMake
| expects the "target" to be a library of some sort. That's not
| the sort of thing I would personally want.
|
| I would want to be able to depend on any target for any
| target.
|
| But again, I could be wrong. I've never been able to
| understand the CMake docs.
|
| [1]: https://news.ycombinator.com/item?id=33885476
| catiopatio wrote:
| That's just the worst of all worlds and makes for an equally
| terrible development experience for everyone.
|
| CLion's native support for CMake is the only thing that makes
| the IDE story palatable, but everything about CMake's
| architecture resists treating CMake as a declarative format
| and performing that kind of intelligent integration.
| dlivingston wrote:
| First, why is it the worst of all worlds? I have a
| consistently good experience using CMake-generated Visual
| Studio projects. Second, what's the alternative? Having
| CMake manage the entire build, down to linkage? What
| benefits does that give over the current situation?
| catiopatio wrote:
| VS seems to be the most usable of CMake's IDE output
| formats, but it still remains an awkward experience:
|
| 1) Two editable sources of truth, one of which is only
| sometimes overwritten when performing a target build,
| depending on whether the CMake inputs have changed.
|
| 2) Non-universal native IDE constructs can only be
| expressed if CMake supports them, and if you use IDE-
| specific CMake features.
|
| VS is as good as it gets, and it isn't that great. By
| comparison, Xcode project support is absolutely terrible.
|
| CMake has a semi-declarative semantic representation of
| your project and its targets, but has to lossily
| translate that into a number of different, incompatible
| project formats, all of which are only capable of
| representing a different incompatible subset of CMake's
| features. In several cases, CMake's features behave
| differently (or not at all) depending on the generator
| being used.
|
| I think GP already thoroughly elucidated most of the
| issues with this model; all of these issues fall out of
| the necessarily lossy, inconsistent conversion to
| incompatible output formats.
| Asooka wrote:
| > Generating a build file for another build system. This means
| that CMake always gives up control of the build. It can only
| tell the other build system the dependency graph and then sit
| back and watch. It can't regulate the build itself.
|
| That is a hard requirement to using Visual Studio and XCode,
| which I wager account for more than 90% of C/C++ projects.
| ghoward wrote:
| Sure, but doing so doesn't mean that the generating build
| system had to have the same model as CMake.
|
| Here's how my build system will do it: the programmer will
| list default build profiles. Then the build system will
| generate Visual Studio or XCode files that include all of
| those default build profiles, but those VS or XCode files
| will simply call my build system with the correct build
| profile.
|
| Thus, when a build is run from VS or XCode, my build system
| is still in full control.
|
| In essence, instead of generating build files for use by
| other build systems, my build system will generate files to
| tell VS and XCode how to call my build system. It will tell
| VS and XCode how to integrate it.
| plorkyeran wrote:
| My experience with build systems that do that is that
| there's consistently IDE features which just don't work
| correctly. The most obvious one is "build current file",
| which is very important for large projects and can't work
| without the IDE knowing how to build things.
| cassepipe wrote:
| Well it seems on topic to bring up xmake. It has no DSL, just
| Lua. Been using for a year (with Cpp. Haven't tried other
| languages with it yet) and I love it
|
| xmake.io
| simplotek wrote:
| These initiatives are quite bluntly idiotic. CMake's scripting
| language is a collosal red herring. CMake's scripting language is
| good enough for all conceivable use cases, and if you feel the
| need to write scripts, let alone complex ones, then you're
| already doing something awfully wrong and you should just reach
| out to the documentation to learn how to do things properly.
| marwis wrote:
| IMHO BSD make and their library of include files is highly
| underrated: PROG=foo SRCS=foo.c MAN=
| .include <bsd.prog.mk>
|
| Very terse, super flexible and easily amenable to tooling (It's
| trivial to generate IDE project files from this).
|
| https://wiki.netbsd.org/tutorials/bsd_make/#index1h2
| https://crufty.net/help/sjg/bmake.html
| cjk wrote:
| I spent several years creating and maintaining a large,
| proprietary build system for a Linux-based operating system at a
| previous gig. Much of userspace was C/C++, and thus used CMake.
| To further complicate things, most of userspace needed to be
| cross-compilable for a macOS-based "simulator" environment.
|
| I ended up being fairly proficient with the "modern" CMake
| language after investing a ton of time into it, but as the size
| of the company grew, I ended up being a bottleneck. Every other
| team found themselves subject to CMake's many footguns, and I'd
| end up having to step in to help.
|
| It was maddening, but I 100% get that other teams just wanted to
| focus on getting their work done, rather than fighting with a
| poorly-documented and frustrating build system.
|
| I, for one, would be very happy to see a new CMake scripting
| language. Ideally, one that is a lot more friendly for beginners
| and occasional users.
| ThouYS wrote:
| CMake truly is a perfect fit with C++. Both suck, but nothing
| less sucky seems to do the job
| xigoi wrote:
| > nothing less sucky seems to do the job
|
| For me, Nim and Nimble work pretty well.
| TillE wrote:
| With C++ you can choose to ditch the old garbage and use just
| the new comfy stuff in a greenfield project.
|
| With CMake, the new stuff still sucks.
| vlovich123 wrote:
| Doesn't Bazel / Buck do a better job? The only downside might
| be IDE integration outside of Google / Facebook but I think
| there's effective polyfills that generate
| compile_commands.json.
| en4bz wrote:
| bazel is trash.
___________________________________________________________________
(page generated 2022-12-06 23:01 UTC)