4 ms·

The comparison to CMake isn't apt: https://github.com/SanderMertens/bake/blob/master/README.md#how-does-bake-compare-to-cmake https://github.com/SanderMertens/

The comparison to CMake isn't apt: https://github.com/SanderMertens/bake/blob/master/README.md#how-does-bake-compare-to-cmake https://github.com/SanderMertens/bake/blob/master/README.md#... CMake projects allow proper recursive inclusion, so this would be sufficient to include 'bar' and link against it: add_subdirectory(bar) target_link_libraries(Foo bar) ...this only assumes that somewhere in the 'bar' directory, 'add_library(bar .....)' is called. Alternately, one can (and often does) use a 'find_package(bar)' call instead of 'add_subdirectory' to pull in a library installed on the system somewhere. The main difference seems to be that bake is configured with a particular json schema while CMake is configured with scripts written in the CMake language. I'm skeptical that the json approach stays as same as advertised once large and distributed organizations use the tool seriously. At scale, I expect a bake json to resemble a maven xml, albeit in json. I'll also note that bake doesn't seem to support a distinct test phase, which will likely cause issues in large organizations; they would need a separate test configuration system on the side somehow.

weberc2 8y ago
Declarative file formats mostly seem to work fine for every other language. The only thing that I can think of that is unique to C++ is that the ecosystem is full of projects which use cobbled-together build scripts in imperative languages, which means your project may need to interface with these scripts; however, a package manager means that only the package maintainer needs to worry about these scripts; not every project that depends on them, so the declarative approach should work just fine as with other languages.
- humanrebar 8y ago
  Yeah. You hit the nail on the head. Lacking a standard package manager, no module system, need for incremental compilation, and semantically significant preprocessor symbols (among other things) make C and C++ require a lot of power tools for building at all correctly. Even relatively cleaner languages like Java need fairly involved declarative config files like pom.xml. > ...only the package maintainer needs to worry about these scripts... Package maintenance is only one part of the puzzle. There are still analysis, code transformation, documentation generation, and other kinds of automation. There's also packaging for different ecosystems. Each package manager, Conan, monorepo systems, and each company specific system out there (maybe the most common concern). A language like python already has standard languages and formats to both keep the number of integration points small and to keep the remaining ones supported. In other words, I expect project.json to mention Doxygen and clang-tidy and DPKG at some point. Otherwise there will need to be pretty flexible ways to expose bake-deduced data to those tools.
  - ajmmertens 8y ago
    Funny you mentioned that- before it was forked bake had doxygen & test framework integration. I'm working on porting the test/doxygen drivers as we speak.
    - humanrebar 8y ago
      I suspect you'll need to iterate or offer a variety of drivers in that space. Doxygen has a lot of configuration needed, often including generation of a suitable Doxyfile. Testing is often just as complicated as the build. There can be interconnected packaging and runtime requirements for integration tests, for instance. You could probably support portable, package-time unit tests without a lot of work though.
- htfy96 8y ago
  > only maintainer will write it In C++ everyone is a combination of developer, tester, package maintainer and deployer. According to my experience, even the best package repos like conan or vcpkg's still lack many important packages and I still need to write my own scripts. The underlying problem is that it takes much more time for a maintainer to create a package description file compared to other languages because of missing dependency list or implicit version requirements, so community (or even a company's funding) simply doesn't work. The end of nightmares can only come from the adoption of modules (expected to appear in C++20) or hiring a number of specialized full-time C++ packagers with fundings at scale of millions from the committee/some organizations/whatever.
ajmmertens 8y ago
Thanks for bringing that up, I agree that the example is quite trivial, though I think it's at least a fair comparison when it comes to general complexity of two simple projects. Regarding find_package; it does sound similar to bake's discovery. There is a not insignificant difference though between how both work in practice. Without going into too much depth, CMake attempts to find a package by looking at (a potentially large number of) system paths. It attempts to adhere as well as possible to the conventions of that platform. On the other hand, bake recursively searches for projects from where it is being invoked, in addition to looking in a "bake environment". The latter is a self-contained, fixed-format directory structure that contains all projects built with bake. A bake environment is by default stored in a user's $HOME folder, but can be configured to (for example) /opt. Bake environments can be easily moved to different directories and even machines. There is nothing inherently right or wrong with either approach, but they are certainly different. Bake's approach was designed to accommodate a scenario where a developer is working on a large number of (potentially shared) projects at the same time, and for that it works really well. Bake has been used for well over 4 years (in various iterations) in big and small organizations. It held up pretty well for large-scale projects, though I should mention that, as with any tool, it can be misused. Big organizations in particular will have to establish conventions and guidelines around using bake, just as they would have to do with any other approach.

weberc2 8y ago

Declarative file formats mostly seem to work fine for every other language. The only thing that I can think of that is unique to C++ is that the ecosystem is full of projects which use cobbled-together build scripts in imperative languages, which means your project may need to interface with these scripts; however, a package manager means that only the package maintainer needs to worry about these scripts; not every project that depends on them, so the declarative approach should work just fine as with other languages.

humanrebar 8y ago
Yeah. You hit the nail on the head. Lacking a standard package manager, no module system, need for incremental compilation, and semantically significant preprocessor symbols (among other things) make C and C++ require a lot of power tools for building at all correctly. Even relatively cleaner languages like Java need fairly involved declarative config files like pom.xml. > ...only the package maintainer needs to worry about these scripts... Package maintenance is only one part of the puzzle. There are still analysis, code transformation, documentation generation, and other kinds of automation. There's also packaging for different ecosystems. Each package manager, Conan, monorepo systems, and each company specific system out there (maybe the most common concern). A language like python already has standard languages and formats to both keep the number of integration points small and to keep the remaining ones supported. In other words, I expect project.json to mention Doxygen and clang-tidy and DPKG at some point. Otherwise there will need to be pretty flexible ways to expose bake-deduced data to those tools.
- ajmmertens 8y ago
  Funny you mentioned that- before it was forked bake had doxygen & test framework integration. I'm working on porting the test/doxygen drivers as we speak.
  - humanrebar 8y ago
    I suspect you'll need to iterate or offer a variety of drivers in that space. Doxygen has a lot of configuration needed, often including generation of a suitable Doxyfile. Testing is often just as complicated as the build. There can be interconnected packaging and runtime requirements for integration tests, for instance. You could probably support portable, package-time unit tests without a lot of work though.
htfy96 8y ago
> only maintainer will write it In C++ everyone is a combination of developer, tester, package maintainer and deployer. According to my experience, even the best package repos like conan or vcpkg's still lack many important packages and I still need to write my own scripts. The underlying problem is that it takes much more time for a maintainer to create a package description file compared to other languages because of missing dependency list or implicit version requirements, so community (or even a company's funding) simply doesn't work. The end of nightmares can only come from the adoption of modules (expected to appear in C++20) or hiring a number of specialized full-time C++ packagers with fundings at scale of millions from the committee/some organizations/whatever.

ajmmertens 8y ago

Thanks for bringing that up, I agree that the example is quite trivial, though I think it's at least a fair comparison when it comes to general complexity of two simple projects. Regarding find_package; it does sound similar to bake's discovery. There is a not insignificant difference though between how both work in practice. Without going into too much depth, CMake attempts to find a package by looking at (a potentially large number of) system paths. It attempts to adhere as well as possible to the conventions of that platform. On the other hand, bake recursively searches for projects from where it is being invoked, in addition to looking in a "bake environment". The latter is a self-contained, fixed-format directory structure that contains all projects built with bake. A bake environment is by default stored in a user's $HOME folder, but can be configured to (for example) /opt. Bake environments can be easily moved to different directories and even machines. There is nothing inherently right or wrong with either approach, but they are certainly different. Bake's approach was designed to accommodate a scenario where a developer is working on a large number of (potentially shared) projects at the same time, and for that it works really well. Bake has been used for well over 4 years (in various iterations) in big and small organizations. It held up pretty well for large-scale projects, though I should mention that, as with any tool, it can be misused. Big organizations in particular will have to establish conventions and guidelines around using bake, just as they would have to do with any other approach.