Coroutines are now in Clang trunk, libc++

Re:Coroutines are now in Clang trunk, libc++ by MereInterest on Friday May 26, 2017 @06:51AM (#14423153)

Cmake is acceptable for distribution, but not for ease of development, in my experience. There should only be a single step needed to generate a correct build, no matter what has changed. Instead, some changes require running make (e.g. modifying existing files), while others require running cmake then make (e.g. adding new files, or changing header file includes). Why would I use cmake when I could just write a makefile to handle everything in a single step?

Granted, I've been moving more towards scons lately, as python is a much easier language to work with. My usual SConstruct will check whether I am making a python extension module, and will download pybind11 if I am. That sort of thing is still possible with make, but starts getting more painful.

[ Parent | on HN ]

Re:Coroutines are now in Clang trunk, libc++ by fest on Friday May 26, 2017 @07:14AM (#14423234)

Having to run cmake before make is usually avoidable.

If you aren't using globbing but are specifying source (and header files) explicitly, just running make will do the right thing. Just running make also checks if you have modified CMakeLists.txt and re-runs config generation.

[ Parent | on HN ]

Re:Coroutines are now in Clang trunk, libc++ by to3m on Friday May 26, 2017 @08:13AM (#14423481)

Yes, don't use globbing to find source files! CMake doesn't record that the file list came from a glob operation, so it doesn't set up the dependency checking to handle it. (Not all targets support this sort of thing anyway. I bet GNU make does a good job of it, especially if you use gcc -MMD and pattern rules; I rather doubt Ninja supports it; Visual Studio definitely doesn't.)

With manually-specified source file lists, using the Ninja, GNU make, NMake and Visual Studio generators, I have had to re-run cmake by hand no more than a few times, each time seemingly due to a bug somewhere. (Possibly my fault... I can't remember having had to do this with my current project.) Aside from that it's good at detecting when relevant files have changed, CMakeLists.txt included, and reinvoking itself as part of the build.

CMake has plenty of horrid parts, and there's probably plenty of reasonable workflows that it doesn't support, but I have to say that I've found the day-to-day workflow perfectly satisfactory...

[ Parent | on HN ]

Re:Coroutines are now in Clang trunk, libc++ by MereInterest on Friday May 26, 2017 @08:26AM (#14423542)

That certainly sounds like an issue with cmake, rather than with globbing in general. With a properly written makefile, or with scons, there is no issue whatsoever in globbing to find source files. This is one of the main reasons that I have stayed away from cmake, because needing to specify an explicit list of all source files is setting myself up for errors in the future.

[ Parent | on HN ]

Re:Coroutines are now in Clang trunk, libc++ by to3m on Friday May 26, 2017 @08:48AM (#14423634)

What's probably happening is that most people don't mind, and the current behaviour maps neatly to the way most IDEs behave. And so there probably isn't the will to change it. CMake does have an issue tracker: https://gitlab.kitware.com/cmake/cmake/issues

[ Parent | on HN ]

Re:Coroutines are now in Clang trunk, libc++ by haldean on Friday May 26, 2017 @01:47PM (#14425882)

Autotools also requires you to explicitly enumerate all of the source files that end up in your build, although it also properly sets up Makefile dependencies so you don't have to re-run autotools when you add a new source file (like you do with CMake)

[ Parent | on HN ]

Re:Coroutines are now in Clang trunk, libc++ by to3m on Friday May 26, 2017 @10:41PM (#14428675)

You typically don't have to do this with cmake either. The build depends on the CMakeLists.txt file (and the files it depends on itself), which is where the list of source files is stored.

[ Parent | on HN ]

Re:Coroutines are now in Clang trunk, libc++ by MereInterest on Friday May 26, 2017 @08:01AM (#14423438)

That's a pretty big if. If I have a standard layout with src and include directories, then I expect everything within the src directory to be included, which requires globbing. If I add a new file, then there is no reason to need to edit the CMakeLists.txt as well. Similarly, header files are explicitly listed in the source files. Having them duplicated in the CMakeLists.txt only introduces potential for error.

In my mind, anything that needs to be specified explicitly is an opportunity for error.

[ Parent | on HN ]