3 ms·

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 fu

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.

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.