[HN Gopher] Ray Tracing in pure CMake
___________________________________________________________________
Ray Tracing in pure CMake
Author : networked
Score : 237 points
Date : 2021-01-09 13:04 UTC (9 hours ago)
(HTM) web link (64.github.io)
(TXT) w3m dump (64.github.io)
| savant_penguin wrote:
| This is an ode to how much you can do with the four arithmetic
| operations and not much more
| unnouinceput wrote:
| I remember writing a ray tracing in 1994 in Turbo Pascal 7.0
| running on 286 under DOS 4.0 at the time. I did it with floating
| numbers, pure mathematical implementation. When it came to
| usability was something like 1 frame every 30 seconds for
| resolution of 640x480 with 256 colors only.
|
| The problem with ray tracing isn't writing one, the problem is
| its usability, to get the most realistic AND fast enough. Mine
| was very realistic for that resolution but the snail FPS was
| something unbearable. Despite my best efforts at the time,
| hardware was not ready. I remember the talk between us (prof.
| assistant, basically a master student and rest of wanna be
| programmers) and we're so sure it would take maximum 5 years for
| ray tracing and photo-realism to become every day commodity. We
| were wrong only by 20 years. Good times.
| pixelpoet wrote:
| 640x480 256 colours on a 286? With only 30 seconds for an
| image, even though it doesn't have a floating point unit? Sorry
| for being a doubting Thomas, but that seems very implausible
| (having spent my life writing ray tracers).
| dahart wrote:
| > we're so sure it would take maximum 5 years for ray tracing
| and photo-realism to become every day commodity. We were wrong
| only by 20 years. Good times.
|
| Yeah that was a very long running joke about ray tracing:
| "real-time ray tracing is only five years away... and always
| will be". ;)
|
| > The problem with ray tracing isn't writing one, the problem
| is its usability, to get the most realistic AND fast enough.
|
| Times sure have changed eh? 640x480/30s is ~ 10k rays/sec. Now
| we have ray tracing GPUs that can do well over 10B rays/sec
| with full floating point. More than a million times faster, not
| even counting precision & scene size, crazy right?! I'm working
| in the field and still blown away by what people are doing in
| real time in the last few years, fully path traced scenes with
| global illumination that are hard to distinguish from
| photographs...
| bawana wrote:
| Please clarify for me the part about the set exec command. You
| create n workers but you pass the whole image size to each. Why
| isn't the image size divided by the number of workers?
| slezyr wrote:
| See the source code, it uses worker_index to find which part of
| the image it needs to process.
| iab wrote:
| Every day we stray further from god's light
| Iwan-Zotow wrote:
| very good porno
| lasagnaphil wrote:
| Oh no... so far the most terrifying title I've seen in HN this
| year. By the way, it's impressive how they even managed to
| multithread this.
| usrusr wrote:
| Someone might be working on an article even worse: list of
| things that raytracers haven't been written in (yet, regularly
| updated)
| kortex wrote:
| Well, if you can store data in icmp packets, I bet you can do
| math, too.
|
| https://github.com/yarrick/pingfs
| acka wrote:
| When someone manages to write a raytracer in COBOL I will be
| truly impressed.
| 0-_-0 wrote:
| There are even Excel ray tracers out there
| Sharlin wrote:
| In fact that's not even difficult, given how both a
| raytracer and a spreadsheet are basically functions that
| assign a value to every cell of a grid.
| dev_tty01 wrote:
| Next thing you know someone will suggest HN with hierarchy
| for repeated and unrelenting topics. Linux ports on home
| appliances, ray tracing, vi vs. emacs, launchd vs systemd,
| walled gardens, .... Oh no, say it isn't so!
| prox wrote:
| Those darn Hackers on hackernews! :)
| master_yoda_1 wrote:
| Hackers works on things which are not trivial.so
| certainly not a hacker
| prox wrote:
| Darn those non-hackers who don't work on non-trivial
| things! :)
| Uehreka wrote:
| To pick from a recent HN thread: A raytracer has probably not
| been written yet using only printf. Who wants the glory?
| Niktator wrote:
| MySQL raytracer: http://www.pouet.net/prod.php?which=83222
| usrusr wrote:
| (PS: would that eventually count as "raytracers, written in
| provocative blog post meme"?)
| amelius wrote:
| Or how about: an LLVM backend for CMake.
| snarfy wrote:
| Calm down Satan.
| kroltan wrote:
| You calm down, we haven't even brought in WebAssembly
| yet!
| turing_complete wrote:
| They were so preoccupied with whether or not they could, they
| didn't stop to think if they should.
| klyrs wrote:
| Funny comment from somebody named turing_complete, innit? The
| fact that they "shouldn't" is what makes this abomination fun.
| xyzzy_plugh wrote:
| I refuse to even look at this. I've seen ray tracing in a PDF
| before but this is too far.
| Someone wrote:
| IMO, this isn't that impressive. Turns out that CMake has a
| scripting language that can be used to implement a ray tracer,
| and do that multi-threaded. The model being rendered also is
| hard-coded in the ray tracer.
|
| I expected a monstrosity that had multiple targets for every
| pixel ("ray arriving at (x,y)", "ray arriving at (x,y) after
| one bounce", etc), with some magic to merge all the outputs of
| the last bounce into an image, say by generating a huge html
| table, with each cell having a different background color.
| tgv wrote:
| Let me tell you one detail: since cmake doesn't have floats,
| they use fixed point arithmetic. LOOK AT IT. You know you want
| too! function(sqrt x res)
| div_by_2(${x} guess) foreach(counter RANGE 4)
| if(${guess} EQUAL 0) set("${res}" 0
| PARENT_SCOPE) return() endif()
| div(${x} ${guess} tmp) add(${tmp} ${guess} tmp)
| div_by_2(${tmp} guess) endforeach()
| set("${res}" "${guess}" PARENT_SCOPE) endfunction()
| fouronnes3 wrote:
| CMake is by far the worst language I have ever worked in.
| Leherenn wrote:
| I think modern cmake mostly has the right ideas, but the
| overall implementation is poor, mainly due to legacy.
| discardable_dan wrote:
| Agreed. I will never understand how a group looked at overly-
| complex Makefiles, determined it was hard to write complex
| build scripts, and concluded: "I should write a Makefile meta-
| language that can generate these." That would be like looking
| at a complex Java codebase and concluding that the best
| solution to simplify it would be to write a Java meta-language
| for generating your classes...
| aidenn0 wrote:
| If you only ever generate makefiles with cmake, then you
| probably don't need cmake.
| kortex wrote:
| I'll tell you exactly how: trying to maintain cross platform
| ITK builds on tons of bespoke HPC clusters and academic
| workstations using the existing build tools became a
| nightmare.
|
| Writing makefiles is extremely repetitive and tedious and
| error prone: precisely the kind of thing to automate. Not
| just makefiles mind you, cmake is designed to automate all
| sorts of build parameters.
| pjmlp wrote:
| I bet you never tried to write large scale Makefiles across
| several OSes, even POSIX ones.
| TheRealSteel wrote:
| Oh thank god, this thread is making me feel much better about
| myself.
|
| I've been trying to integrate OpenCV's C++ library with my own
| C++ code (not involving Python), _with_ the additional contrib
| modules (meaning I have to compile OpenCV myself), for multiple
| platforms, and I got stuck on CMake for so long it made me
| question if I was just a total idiot and should give up on
| programming forever.
| jcelerier wrote:
| to give another data point: I was given a project a couple
| weeks ago that was using visual studio solutions and opencv +
| contrib modules - I fighted 3 hours with making the .vcxprojs
| work on my machine before porting the whole shit to cmake in
| 15 minutes.
|
| Using OpenCV was just a matter of
| find_package(OpenCV 3.3.1 REQUIRED)
| target_include_directories(theApp PUBLIC
| ${OpenCV_INCLUDE_DIRS})
| target_link_libraries(theApp PUBLIC ${OpenCV_LIBS})
|
| and everything worked, so I'm curious about what failed for
| you
| TheRealSteel wrote:
| Thanks for your reply.
|
| Will this include the contrib modules even for Android? And
| iOS?
|
| Once I sat down and read the Cmake basics, yes, it was easy
| enough to get OpenCV working with basicallly the code you
| posted, except I couldn't find a way to include the contrib
| modules in an Android version, it would always complain
| Aruco wasn't there.
|
| Until I went and compiled OpenCV myself, and _that_ was the
| part that was a massive pain in my ass - CMake failing to
| include architecture information in the library files
| unless you specify it on the command line _before_ running
| Cmake GUI, even tho it _is_ an option in the GUI. Tho
| perhaps that 's more of a failing of the OpenCV build
| script than Cmake itself?
|
| I did just recompile OpenCV myself, so I did get there in
| the end and it's all working now, but I'm sure I'll be
| tweaking all parts of this project for months to come so if
| there's an easier/proper way, I'm happy to learn.
|
| It also needs to be statically linked.
|
| Note: I'm not a real programmer, I don't know enough to
| have even been able to get an entry level job in the
| industry yet, I'm an idiot that doesn't belong on this
| website. I'm just trying to learn as I go.
| seabird wrote:
| Humility is good, but it's important to acknowledge that
| CMake very often feels awful. I consider myself a
| competent developer and it's still pulling teeth trying
| to get what I want out of it.
|
| Some things will get easier with time, and a lot of other
| things are going to suck shit forever. Keep on truckin'!
| kortex wrote:
| > Tho perhaps that's more of a failing of the OpenCV
| build script than Cmake itself?
|
| That is exactly what that is. Cmake is extremely
| powerful, and it lets library authors make build
| configuration that is quite often too flexible. Combine
| that with no standardized package manager for c or c++
| for decades, and much cmake evolution over that time,
| means you encounter many different ways to solve
| problems.
|
| Opencv is up there for most complex cmake projects. Only
| behemoths like VTK, ITK, and ROS beat it in complexity of
| the build.
|
| Also, don't beat yourself up too much. :)
| jcelerier wrote:
| > Once I sat down and read the Cmake basics, yes, it was
| easy enough to get OpenCV working with basically the code
| you posted, except I couldn't find a way to include the
| contrib modules in an Android version, it would always
| complain Aruco wasn't there.
|
| If this worked on desktop, I would assume this to be a
| bug in the OpenCV cmake files, there's no reason for
| aruco not to be in OpenCV_libs if my understanding of the
| OpenCV build system is correct (but then I did not really
| have to fight it)
| jpm48 wrote:
| plus 1 for this, I have been using CMake with my students
| for a year (moving from qmake) and this in conjunction with
| vcpkg to install stuff has been a breeze. This book is
| great too https://crascit.com/professional-cmake/
| physicsguy wrote:
| Simultaneously love and hate this
| tuankiet65 wrote:
| Here's a performance figure on my i5-3210m (2 core, 4 threads)
| when using 4 processes:
|
| * 64x64: 14.561s
|
| * 256x256: 226.28s, 15x compared to 64x64.
| pizza234 wrote:
| > * 256x256: 226.28s, 15x compared to 64x64.
|
| Basic ray tracers compute one ray for each pixel (without
| reflection/refraction), so that this increase in time is
| expected, as it's roughly 2562/642=42. This is also due to the
| fact that each ray is independently computed.
|
| I don't know if sophisticated ones can save some (rays)
| computation by interpolating.
| Blikkentrekker wrote:
| I must say that completing this article leaves me with a feeling
| not too dissimilar from that mixture of awe and disgust when I
| finished reading _Uwa-Koi_.
| knorker wrote:
| Well well well, we finally found something CMake can actually do.
|
| Please, everyone, stop using CMake. It doesn't do its one job.
| skohan wrote:
| What's wrong with CMake?
| IshKebab wrote:
| The language is _extremely_ error prone. It 's like they
| looked at Bash and thought "hmm, too safe".
|
| Everything is a string, even lists are just semicolon-
| separated lists. The argument expansions rules for calling
| functions are literally impossible to remember. All variables
| are implicitly defined as empty strings. Typos silently break
| things. `if` is completely broken. The separation of the
| configure step from the build step is needlessly confusing
| and makes some things impossible. This is just scratching the
| surface.
|
| It does have a couple of redeeming qualities: they have a
| pretty great versioning mechanism which allows them to make
| breaking changes. Though inexplicably they haven't used it to
| fix any fundamental flaws, only little tweaks. And most
| importantly it has been around for ages so loads of the many
| many weird C++ compilation knobs have been solved.
| dev_tty01 wrote:
| > It's like they looked at Bash and thought "hmm, too
| safe".
|
| One of my favorite comments in a while. :-)
| cycloptic wrote:
| >The separation of the configure step from the build step
| is needlessly confusing and makes some things impossible.
|
| I'm confused. How do you propose CMake supports all those
| build generators without doing this?
|
| (PS. I really don't think the syntax is that bad, aside
| that it is jarring for C programmers, most complaints are
| overblown and you get used to it once you learn the rules.
| It might be interesting if someone made a CMake variant
| with a less obscure syntax but I don't see much motivation
| for that to actually happen)
| kevin_thibedeau wrote:
| The syntax has improved slightly in recent releases with
| the target family of commands. You just have to know what
| legacy parts to avoid which is itself a burden. Still it
| beats digging into the bowels of autotools.
|
| I do fantasize about a new Cmake frontend implemented
| with Tcl scripting. That would be far more consistent and
| flexible and you can disable much of the language by
| default to minimize footbullets then allow commands to be
| reenabled for times they're needed.
| cycloptic wrote:
| I guess I just don't see where there are footguns and
| unsafety here. Build scripts are intended to operate on a
| known, fixed set of inputs.
| bluGill wrote:
| The syntax is weird and inconsistent. Built ins are case
| insensitive, but user defined functions are sensitive. No way
| to return values from functions, except by jumping to the
| scope of the caller and changing its variables unexpectedly.
| (Better hope you know what the caller does)
|
| That isn't a complete list .
|
| Despite the above cmake is your best choice of build system
| for C. Though some competitors could overtake it.
| jmagoon wrote:
| My least favorite part is how completely impossible it is
| to discover all the implicit variables set by other cmake
| files, and there's no common convention, so some libraries
| are like ${ZLIB_INCLUDE_DIR} and some are
| #{zLib_INCLUDE_DIRS} and you have to just manually try a
| bunch of combinations to finally find what works because
| the scripts themselves use weird string based
| metaprogramming to build the variables themselves.
| andi999 wrote:
| On top of that I found the documentation and the book
| terrible. I thought it might be easier to understand what
| it does by reading the source code (didn't try yet)
| ahartmetz wrote:
| The documentation is "complete" in the way that some
| manpages are - the biggest problem with it is the lack of
| best practices guidance. About books, I believe that good
| ones exist now. The official CMake book is not among the
| good ones - last time I checked, it was ridiculously
| outdated (and IMO not even very good at the time it was
| written).
|
| I _have_ extracted some knowledge from the source code.
| It 's more underdesigned than overdesigned and I think
| that's the better side to err on. Kinda awkward but you
| can figure it out.
| appleflaxen wrote:
| which competitors?
|
| any thoughts on why are build tools so hard to get right?
| MaxBarraclough wrote:
| I agree that CMake is pretty awful, [0] but I'm not convinced
| that we'd be better off using its immature competitors,
| especially considering the fragmentation that would bring.
|
| [0] https://news.ycombinator.com/item?id=24203172
| mhh__ wrote:
| I'm increasingly convinced that a script in a real
| programming language is the way forward.
|
| The D compiler used to have a bunch of fairly flaky makefiles
| (different make vendors => pain), but now there's a shebang
| script written in D that not only does it's job well but also
| handles args properly and to top all that off is actually
| readable by people who aren't used to building software on
| Linux
| ajconway wrote:
| There seems to be a kind of "network effect" here with CMake,
| considering how popular it is among C/C++ projects.
|
| Meson is more or less equivalent in the functionality it
| provides. There is also Gradle, but it doesn't seem to have
| gained much traction outside of Android development.
|
| My personal favorite is Bazel (and others from the Blaze
| family of build systems). It uses a python-based language for
| describing build rules, an extensive documentation and
| developers that respond to issues. Among the downsides is the
| lack of proper dependency management which is critical for
| public, open source projects.
|
| There is also Nix which takes it even further, but it
| requires much more involvement from the developer.
| jcelerier wrote:
| > Meson is more or less equivalent in the functionality it
| provides.
|
| but meson needs everything to be quoted which is frankly a
| gigantic PITA - like, look at that, there's more quoted
| stuff than anything else:
| https://mesonbuild.com/Generating-sources.html
| MaxBarraclough wrote:
| I've not used it, but that wouldn't bother me too much.
| It's far preferable to a language like Bash where you're
| permitted to omit quotes, but consequently it's a
| minefield to write scripts that can robustly handle
| strings containing whitespace (e.g. arbitrary file
| paths). The Ada philosophy has it right: readability and
| correctness far outweigh writeability.
| milanove wrote:
| Waf is another interesting build system I've seen used in
| production. It's config is done with Python scripts, which
| is cool.
| MaxBarraclough wrote:
| There's also Premake, [0][1] Buildout, Ninja, SCons, and
| no doubt there are others. qmake was recently deprecated.
|
| It would take a _lot_ to persuade me to move away from
| CMake and to use something 'non-standard' that few
| developers are familiar with:
|
| * Excellent support for command-line builds on Unix
|
| * Excellent support for Visual Studio
|
| * Excellent cross-platform package-detection. (Acid test:
| Can it detect and link against OpenCL without me having
| to write my own cross-platform OpenCL-detection script?)
|
| * Excellent documentation, including clear and consistent
| best practices and design patterns
|
| * A sensible language, whether a scripting language or a
| declarative language. Must follow the principle of least
| astonishment and be relatively free of foot-guns. (CMake
| fails tragically on both counts.)
|
| [0] https://premake.github.io/
|
| [1] https://en.wikipedia.org/wiki/Premake
| knorker wrote:
| I can't speak for MSVC support, but to me CMake fails all
| other bullet points. _especially_ cross-platform package
| detection.
|
| I haven't seen anything except autotools get this right.
| MaxBarraclough wrote:
| > especially cross-platform package detection
|
| I disagree here. CMake has working _FindXyz_ modules for
| most major libraries. To write one of those modules is an
| exercise in soul-destroying tedium, but there 's a pretty
| impressive body of existing modules out there, many of
| them officially bundled with CMake.
|
| When used correctly, both CMake and Autotools are capable
| of robust package-detection.
|
| Regarding point 1: CMake works pretty well on Unix, but
| it's a pity there's a runtime dependency on the CMake
| package. Autotools is much better in that particular
| regard: just about any Unix system can run a _configure_
| script, as it 's just a plain old shell script.
|
| CMake certainly falls short on the final 2 points, as I
| rambled about at
| https://news.ycombinator.com/item?id=24203172
|
| It's too late for me to edit my earlier comment, but
| here's another alternative to CMake for the list: Bazel.
| slavik81 wrote:
| I used Waf before I tried CMake, and I found the latter
| much easier to understand. The CMake language is a mess,
| but the compilation model is simple.
| kortex wrote:
| What we could really use is some new declarative syntax that
| interoperates with existing cmake projects.
|
| There is already talk of such a system and even some
| implementations. I am sure many people have thought to
| themselves "This is so complicated! So much legacy cruft! I
| bet I could build a way cleaner c/c++ build system! " only to
| run into all of the complexity of cross platform c++.
|
| I highly doubt there will be a cargo for c/c++, because it
| simply isn't rust.
|
| https://gitlab.kitware.com/cmake/cmake/-/issues/19891
|
| https://gist.github.com/stryku/4c69aa510711c9da6705fa4df4545.
| ..
| humanrebar wrote:
| I like declarative approaches, but there's such a long tail
| of weird things to support. I'm skeptical something
| declarative can do the job on its own.
|
| Maybe some time after modules become available and then a
| known quantity.
| discardable_dan wrote:
| I still don't understand why cmake/autotools are seriously
| considered. If you have a tool that is hard to do complex
| things with (i.e., complex Makefile operations), the solution
| should _not_ be a tool to generate input for that tool (i.e.,
| CMake/autotools generating makefiles). We shouldn't use a build
| system whose artifacts are scripts in a cruftier build system;
| we should replace the universal build system whole-cloth. Even
| the portability argument fails: if any modifications to the
| build system require installing the respective meta-tool
| (cmake/autotools), the generated Makefile is nearly-useless for
| anyone trying to modify that codebase in any substantial way.
| We need tools that do the actual building, not Makefile meta-
| languages.
| knorker wrote:
| Well, first let me say that I agree that neither cmake nor
| autotools is perfect.
|
| I _am_ saying that cmake is fundamentally broken and unfit
| for purpose even in addition to what you mention. I 've
| mentioned some in another comment here, but really why cmake
| should be thrown in the garbage is too long a rant to fit
| into a comment field.
|
| I am VERY interested in hearing new ideas. If you have a
| truly better way, then I want to use it.
|
| Though I'm not sure why you say generating code is so bad.
| Code gets compiled to machine language, and (especially with
| optimizations and all the new fancy instructions) are not a
| thing that most people usually look at anymore.
|
| Yes, actual developers need automake/autoconf installed. Of a
| sufficiently recent version. But what exactly is your
| suggestion? Autotools at least makes this an issue only for
| the developers (and not even all of them, since they may not
| need to change things), not for the orders of magnitude more
| users.
|
| But this is not a unique thing to developers. There may be
| other generated code. E.g. they need to have protobuf
| compiler installed, with all the plugins required. End users,
| even those who build, don't. Developers who don't modify
| those parts don't.
|
| But here's the main thing though: Any portable build system,
| that _already requires EVERY user to have that build system
| installed_ , is DoA for being a viable portable build system.
|
| It's incredibly frustrating to download a package, only to
| find that the build system the author in their infinite
| wisdom chose to use, has not been ported to your platform (or
| if it has, you have to yak shave for a few hours to get it
| and its dependencies installed). So you can't compile the
| thing.
|
| The beauty of autotools is that it "compiles" to a "virtual
| machine" (shell) that will truly run anywhere. Nowadays even
| on Windows, which now ships bash.
|
| CMake too fails on this aspect, in addition to all the other
| aspects this box won't be able to fit.
|
| But please, I truly mean that if you have a better way, then
| I do want it. It's incredibly hard to build something
| portable though. Hence the minimal dependency of "just a
| POSIX shell" for autotools.
| kortex wrote:
| > Any portable build system, that already requires EVERY
| user to have that build system installed, is DoA for being
| a viable portable build system.
|
| I've voted this post down for this in particular. It is
| truly an absurd criticism, especially when you refute it
| yourself when you admit bash on Windows is a relatively new
| phenomenon (and I still struggle with bash env on Windows).
| If you use a build system, you need a build system
| installed, full stop. Cmake is pretty easy to bootstrap on
| a new host with minimal assumptions. Literally just
| `./bootstrap; make` on basically any 'nix.
|
| Cmake is designed to run truly anywhere, with many backing
| generators, not just make. It doesn't even assume a posix
| shell iirc.
|
| Sounds like many of your complaints are with the library
| authors not writing with portability in mind.
| cycloptic wrote:
| >Any portable build system, that already requires EVERY
| user to have that build system installed, is DoA for being
| a viable portable build system.
|
| Why? I don't see how it's different from requiring a user
| to install a compiler to build a particular language.
| Operating systems don't have every compiler installed by
| default. To fulfill your requirements, one would have to
| re-implement every build system and compiler in POSIX
| shell. Honestly the "better way" that I see a lot of
| projects going with is to just support multiple options for
| build systems, because there is no one perfect solution
| that is going to work on all platforms.
|
| The elephant in the room here is windows, and at this
| current point in time, CMake is about as portable there as
| autotools because Visual Studio has built in support for
| it.
| knorker wrote:
| > Why? I don't see how it's different from requiring a
| user to install a compiler to build a particular
| language.
|
| The various build systems I've seen, including CMake, are
| portability projects in themselves. Yes, to build a C++
| program you need a C++ compiler. But if it's using CMake
| then you need CMake. Oh, but you don't have that. Ok, now
| you have to install that.
|
| Oh, it requires Python X.Y (I'm not saying CMake does,
| but I've seen others that do, and CMake has other similar
| things)? Oh, this system doesn't have that. So now I need
| to build Python from source. Does Python have any
| dependencies, perhaps? (or worse, you have to use
| backports, which pull in 1000 dependencies so that now
| you have a frankensystem)
|
| If you've ever been at the point where two steps down the
| dependency chain you have to build something as
| fundamental as Python, then you probably know that this
| is not a fun experience. And in fact you may run out of
| disk space, several gigs of source and object code later.
| (not every system is a 100TB server)
|
| The whole thing about portability is that it should
| actually work even on systems the original developer does
| not have access to. If all you need to support is Ubuntu
| 18.04 (or newer) and Windows, then why not just have a
| Makefile and a MSVC project file? That would be much
| easier than CMake or autotools.
|
| Oh, and I've also been hit by dependencies of the build
| system being too NEW. E.g. CMakeList.txt using features
| removed in newer versions.
|
| And that's how autotools is different. The ONLY
| dependency is a POSIX shell. Do you have that? Then you
| can build.
|
| The number of times I've seen CMake try to link with
| "-llibfoo" (it's "-lfoo") or be entirely confused about
| how I'm not running the exact same system the developer
| is, I can't even count. (e.g. failing to build because
| "this is not an amd64 system"... uh, yes it is, with zero
| logs about why it thinks that)
|
| > The elephant in the room here is windows, and at this
| current point in time, CMake is about as portable there
| as autotools because Visual Studio has built in support
| for it.
|
| Well that just means CMake has nothing at all going for
| it, if they are as portable.
| cycloptic wrote:
| I've built cpython, it's about as inconvenient as
| building the compiler and runtime for any other major
| language. What OS ships binaries for gcc/clang but not
| python? I can't say I've seen any Linux distros that
| don't have it.
|
| >Well that just means CMake has nothing at all going for
| it, if they are as portable.
|
| Sorry, just to be clear, Visual Studio does not have
| built in support for autotools. (Unless they added it
| recently and I wasn't aware) But, there are a number of
| other less convenient ways to get that to work on
| Windows.
| jcelerier wrote:
| > But if it's using CMake then you need CMake. Oh, but
| you don't have that. Ok, now you have to install that.
|
| you don't, CMake is able to bootstrap from nothing, it
| only requires a C++ compiler
|
| > The whole thing about portability is that it should
| actually work even on systems you do not have access to.
| If all you need to support is Ubuntu 18.04 (or newer) and
| Windows, then why not just have a Makefile and a MSVC
| project file? That would be much easier than CMake or
| autotools.
|
| having been in that exact place it's definitely not true
| pjmlp wrote:
| Windows is not the only non-UNIX OS around.
| mxcrossb wrote:
| I absolutely despise cmake. But autotools is even worse, so
| it's what I end up using. I haven't found another approach
| which handles my needs.
| andi999 wrote:
| What are the needs
| thebruce87m wrote:
| If you're going to tell us what not to use then at least
| suggest an alternative.
| knorker wrote:
| autotools. You may not like it, but it does work.
|
| If you like CMake more, that would be a good argument if
| CMake worked. But it doesn't. So in the choice between the
| thing that works, and the thing you may like more, please do
| go with the one that works.
|
| E.g. this comment I just wrote:
| https://news.ycombinator.com/item?id=25702345
| jcelerier wrote:
| if CMake works for LLVM, Qt, KDE, ReactOS, OpenCV and all
| the other projects in vcpkg there's some chance it's
| working for whatever your project is
| knorker wrote:
| Yes, it could be that project after project after project
| using cmake is just "holding it wrong", and that's why it
| doesn't build on aarch64, openbsd, intel x32, MIPS, with
| some dependencies in nonstandard locations, etc... etc...
|
| It could. But it's an incredible coincidence that it's
| always cmake projects.
|
| Generally on nonstandard installs the others (e.g. scons)
| won't even run, so portability of the conf is not
| relevant.
| flohofwoe wrote:
| The scripting language is bad, most cmake scripts are much more
| complex than they should be, but cmake does a lot of things
| under the hood that make multi- and cross-platform development
| easier (for example: being able to build with the Visual Studio
| compiler without running in the "Visual Studio Developer
| Command Prompt").
|
| A lot of fancy new build tools don't even have proper Windows
| support.
| knorker wrote:
| I keep running into CMake based things not being portable,
| and being broken. And pretty much every single time cmake
| fails, it does not have ANY log AT ALL of what it did, and
| why it thinks libfoo is not there.
|
| Take autotools. You get EXACTLY what it did, and you see why
| it failed. With CMake it just goes "you don't have X
| installed". But I do. It's right there. CMake refuses to say
| under what cmdline or whatever it tried, and what the error
| was. Just "X IS NOT THERE!".
|
| And then it depends on some version of cmake being installed,
| which it may not be.
|
| I don't do windows coding, but shouldn't autotools be more
| viable now that Windows ships with bash?
|
| But even if not, CMake stuff _as a rule_ is not even portable
| between different flavors of Unix, so why even use CMake if
| it 's only going to work on Ubuntu more recent than 18.04 or
| whatever? It's not a silly suggestion. OpenBSD generally just
| has raw Makefiles.
| linkdd wrote:
| I never managed to get CMake to work out-of-the box on
| Windows.
|
| I always end up vendoring the dependencies, because it's
| too tedious to find the correct installed libraries in a
| cross-platform way.
|
| autotools are great, but at the same time it's a
| monstrosity, and easy to misuse (you should never commit
| the configure script, because it's the autotools that are
| supposed to generate it according to the platform it's
| running on).
|
| For C++ dev, I did take a look at buck[1], but it doesn't
| really support Windows platforms.
|
| I wish we had something like cargo (IMHO, the tooling is
| one of the top reasons of Rust's success), in the meantime
| simple Makefiles do the job perfectly.
|
| 1 - https://buck.build/
| admax88q wrote:
| > autotools are great, but at the same time it's a
| monstrosity, and easy to misuse (you should never commit
| the configure script, because it's the autotools that are
| supposed to generate it according to the platform it's
| running on).
|
| The configure script is not generated according to the
| platform it is running on. The whole reason tbe configure
| script is such a monstrosity is because its supposed to
| be portable, its written in the lowest common denominator
| of shell. You are supposed to distribute it. Its also
| fine to check in if you want end users building directly
| from VC rather than from tarballs. Just dont modify it by
| hand.
| linkdd wrote:
| From my experience, `autoreconf -i` is responsible for
| generating the configure script from a configure.ac file,
| so I assumed some platform-specific logic was happening.
|
| I always wrapped it up in a autogen.sh script that I did
| commit. Also, end users generally prefer prebuilt
| binaries, if one wants to compile the software
| themselves, I expect him to have autotools installed, and
| mention it as a requirement in the README.
| knorker wrote:
| I would say that best practice is to NOT commit the
| generated files, but DO include them in release tarballs.
| Because release tarballs are exactly what need to be
| portable to all your users.
| vlovich123 wrote:
| You probably may want to use Bazel. Buck's Windows
| support at Facebook was fine (most all the PC oculus
| stuff is built with Buck) but I don't know what state the
| OSS version is in (maybe technically has support but the
| internal pieces that make it work well don't have OSS
| equivalents that are decoupled from other FB-internal
| things).
| yongjik wrote:
| Everyone's experience is different, but that's very
| different from my memory of autotools - a Turing-complete
| macro processor which generates several thousand lines of
| pre-modern shell script with embedded C source codes. When
| anything goes wrong, it's pretty much impossible to match
| it to the original macro definition. Just so that one can
| hypothetically build the project in an ancient UNIX system
| which is so old that its shell doesn't even have functions.
| admax88q wrote:
| Its difficult to match the origibal macro, but dead easy
| to match into the shell script.
|
| If youre just trying to get something to build as a user,
| its actually quite easy to read the configure script and
| see why its failing. The accompanied config.log is also
| quite detailed.
|
| Autotools are not the best, but i always prefer building
| autotools packages over cmake. Worst case i can modify
| the configure script directly.
| knorker wrote:
| While I've not had that problem, I can see that it's
| nonobvious. But it's years between me looking at the
| actual compiled output. I look at assembly output more
| often, and most people never even do that.
|
| What I mean though is that ./configure outputs a
| config.log that says exactly what was done. Exactly what
| command line was run and exactly what the error was.
|
| I guess I'm confused why you're even looking at the
| compiled scripts. Would you not look at logfiles and
| stderr output before you start looking at assembly?
|
| CMake doesn't. The logs are completely useless, even when
| I get a CMake expert to come and agree, yes that's
| useless.
|
| With autotools you can see that it failed to build
| because it couldn't find library foo when building with
| "gcc blah blah blah", and you go "well yeah, you need
| -L/opt/foo/lib", so you just add that. (or pkg-config
| equiv).
|
| CMake, on the other hand, seems to force you to look at
| CMake "source code" (CMakeLists.txt), which is a horrible
| mess. I'm not saying autotools isn't (yay, m4 :-( ), but
| the point is you don't have to, because it actually logs
| what it does.
|
| So this is one of the many many reasons CMake sucks.
| yudlejoza wrote:
| I just spent some time searching for m4 opinions on HN
| and it's more like a love-hate than hate-hate.
|
| It looks like if you dive head first into learning
| autotools, then m4 is going to look like nuisance.
|
| But if you allocate time to learn m4 for what it is,
| instead of just something you have to put up with as part
| of your autotools adventure, then you'll hate m4.
|
| m4 is the only (or one of a very few) well-known general-
| purpose language-agnostic macro processor I know of.
| knorker wrote:
| I don't hate m4. Could be worse, could be better.
|
| I used to build websites using m4 back in the 90s. Back
| when static site generats were popular, before the latest
| slight resurgence.
|
| To misquote Mitch Hedberg: People either love it or hate
| it, or they think it's ok.
| jcelerier wrote:
| > What I mean though is that ./configure outputs a
| config.log that says exactly what was done. Exactly what
| command line was run and exactly what the error was.
|
| ... so does CMake ? you get log of the errors in
| CMakeFiles/CMakeError.log, and you can trace what happens
| line by line in a very verbose way with cmake --trace (or
| cmake --trace-expand if you want variables to be
| expanded)
| fbkr wrote:
| Could you explain how cmake stuff isn't portable or broken
| between different flavors of Unix? I comfortably maintain
| CMake builds that work on linux (with centos, ubuntu and
| arch), macos and windows without much trouble.
|
| If you mean cmake versions, I'm not sure what you expect,
| should cmake just freeze in time and stop adding features
| so someone gets to use cmake from 5 years ago?
|
| Also, the bit about autotools on windows is silly. If it
| can't build native windows stuff, it's not at all viable
| for windows.
|
| I also dislike cmake (particularly dependency management)
| and wish for something better, but I think our criticisms
| should be well-founded.
| kortex wrote:
| > But even if not, CMake stuff as a rule is not even
| portable between different flavors of Unix,
|
| Not sure what your experience has been but I've had zero
| problems with cmake portability on nixes.
|
| Raw makefiles are so much worse from a maintainability
| point of view.
|
| I find it kinda fascinating to be honest. Two devs come to
| totally opposite conclusions.
|
| Also to get more logging try this:
| https://stackoverflow.com/a/22803821/3988037
| flohofwoe wrote:
| I've never seen an autotools- or make-based project which
| builds out of the box on Windows in cmd.exe. Telling people
| to install cygwin just to build a project simply isn't
| viable when the default compiler toolchain on Windows is
| Visual Studio. Also it's not about building projects alone,
| cmake is also a project file generator for IDEs (in my case
| that was the actual reason why I switched to cmake from my
| own project file generator for Visual Studio and Xcode).
| knorker wrote:
| Interesting. Why do they fail with autotools?
| flohofwoe wrote:
| I don't know, I guess each project fails in a different
| way (my experience was mostly with libcurl before it came
| with cmake support), but IME projects which come with a
| Makefile or use autoconf don't care about non-UNIX-y
| operating systems, while (again: IME) a CMakeLists.txt
| file is often a sign that the project will also build on
| Windows with MSVC.
| asddubs wrote:
| I'll agree CMake is pretty rough to get into, but what makes
| you say it doesn't do it's one job?
| knorker wrote:
| It doesn't produce portable projects. If all you wanted was
| Linux (or often "Ubuntu compatible") then why not just have a
| raw Makefile?
|
| It doesn't log what it attempted, or why it failed.
|
| It can't find out how to link binaries (always awesome to set
| up som execsnoop (because no logs, remember) only to see that
| it tries to link with "-llibfoo". In what world could that be
| correct?. And again it doesn't log how and why it chose that)
|
| I could go on, but it's too much for a comment field.
| mkl95 wrote:
| I have mixed feelings about CMake. Non trivial scripts look
| like an spaghetti ball, but it's an extremely powerful
| spaghetti ball.
| chubot wrote:
| This is cool, someone should port this to bash, which also only
| supports integers.
|
| Then I can use it as a benchmark for https://www.oilshell.org :)
|
| Also bash can do the multicore part very easily with processes,
| like cmake.
| gumby wrote:
| > This is cool, someone should port this to bash, which also
| only supports integers.
|
| With a little bitfield support (you could always call out to dc
| but you can do boolean arithmetic directly in bash) you can
| simply implement IEEE 754 in bash.
| dgellow wrote:
| Wow, the implementation doesn't even look that horrible!
| Fascinating, crazy project.
| hzhou321 wrote:
| I think this is a demonstration why CMake is bad.
|
| Unless it's a general purpose programming language, being Turing
| complete should always be listed in the "Con" side. It literally
| means the effort needed to understand its complexity can be
| unbounded.
| kortex wrote:
| Cmake isn't the problem, it's a solution to the complexity of
| building huge c and/or c++ projects such as VTK such that you
| can run on many different OSes, arches and platforms, with
| hundreds of different build options.
|
| That is just what you get with legacy build systems.
|
| Disclosure: I work at Kitware.
| vlovich123 wrote:
| I think Skylark (the language for Buck/Basel) represents an
| interesting compromise here that I like better, even though
| in the past I was a huge Cmake advocate.
|
| The majority of rules are declarative and easily understood.
| Python (or at least a dialect extremely close to Python) is
| how you extend and write new rules. The two live in very
| different files (declarative rules are in BUCK/BUILD files,
| .bzl files contain the imperative definitions of rules, and
| various other conventions control how you deal with platforms
| (ie select rules).
| gumby wrote:
| I think of CMake as a coin with two faces: on one side is a
| cool engine that manages dependencies and can somehow wrangle
| Make/xcodebuild/ninja et al. On the other side is a dreadful
| interface (presumably due to legacy constraints) that you
| have to gingerly manipulate in the hope that it will cause
| the proper state changes on the other side so that it can
| generate the result you want...when I don't actually know
| what the internals of say Xcodebuild are.
|
| It's sort of like using Italian to correspond with someone
| when you know Latin but not Italian.
|
| If the code base really looks like that it might be
| interesting to implement a different front end. Even XML
| would be better.
|
| On the other hand I couldn't imagine working without it and
| would be happy if it supported more languages (I only use it
| with C and C++).
| tdiff wrote:
| So far the funniest bug with cmake I've fixed was when we were
| accidentally setting a variable with name '0' to a value '1'.
| Later on, in other module, we were checking if some other
| variable was equal to '0' which was interpreted by cmake as a
| variable reference so the actual check was with '1'.
___________________________________________________________________
(page generated 2021-01-09 23:00 UTC)