8 ms·

Show HN: Bake – A modular build system and package manager for C/C++

132 points by ajmmertens 8y ago

mehrdadn 8y ago
Is this related to Bakefiles? There's already something with that name. [1] [1] https://bakefile.org/ https://bakefile.org/
- naniwaduni 8y ago
  It's like the second name everyone comes up with. There are at least five build systems (or adjacent) named bake. Probably a few orders of magnitude more.
  - deleted 8y ago
    [deleted]
- metahost 8y ago
  No, they seem unrelated.
saagarjha 8y ago
Interesting README: > The Dutch IRS has a catchy slogan, which goes like this: "Leuker kunnen we 't niet maken, wel makkelijker". Roughly translated, this means: "We can't make it more fun, but we can make it easier". If only filing taxes in the U.S. was like this… > Bake does not collect any information when you clone, build or publish projects. It's sad that this needs to be said.
- cbcoutinho 8y ago
  I moved to the Netherlands five years ago from the US - dealing with the tax agency here is such a breeze compared to the IRS.
  - kartikkumar 8y ago
    Having lived in a bunch of countries over the past decade, it's only when I moved back home to NL that I fully appreciated how easy things are. Firstly, digital filing is the norm and for "simple" returns, just works. Secondly, if you ever have a question, you can just call the tax authority on their free phone number, and pretty much ask them anything related to individual or business tax returns.
    - mattkrause 8y ago
      I once had to call the IRS for something and it also “worked”. The wait time was pretty reasonable (5 min or so), the person I spoke with was polite, knowledgeable, and actually resolved the problem on the first try. It was heads and shoulders above most interactions I’ve had with with ISPs, big banks, and the like, where you get transferred around between departments that don’t seem particularly interested in helping you out....
  - IshKebab 8y ago
    In the UK most people don't have to file taxes at all. Can't get easier than that.
    - geezerjay 8y ago
      How much is that due to the UK being a surveillance state?
      - IshKebab 8y ago
        None.
- Teknoman117 8y ago
  The worst part is that a large portion of the push back against improving the tax system here in the US is all the tax software companies. Intuit (and H&R Block) spend millions every year lobbying against tax code simplifications or at least simplifying how you interact with the IRS.
  - geezerjay 8y ago
    Someone has to keep breaking windows for the good of the economy.
bake 8y ago
I'm honored
- j1elo 8y ago
  So what I understood from the readme is that all dependencies would also need to be configured around Bake, is that correct? I guess this will be the main chicken and egg problem, as with other build tools, given the variety of tools that exist and are used across different libraries. Although I've found that autotools tends to be a common denominator in most of the ones I've had to work with... A minor detail: the table under Template Functions is not properly formatted and Github doesn't render it as a table.
  - ajmmertens 8y ago
    Thanks for finding the formatting issue, fixed it! You don't need to specify all dependencies "the bake way". If you want to link with a non-bake C library (like pthread or dl), you can configure it like shown here: https://github.com/SanderMertens/bake#can-i-link-with-non-bake-libraries https://github.com/SanderMertens/bake#can-i-link-with-non-ba... It is also possible to wrap existing libraries in bake projects. This section of the README describes how: https://github.com/SanderMertens/bake/blob/master/README.md#integrating-non-bake-projects https://github.com/SanderMertens/bake/blob/master/README.md#...
    - j1elo 8y ago
      Oh sorry, I hadn't read the whole document. Thanks for the link, now I'll finish reading it!
Ericson2314 8y ago
My two favorites parts: - always cross: native builds are just build=host builds. - preprocesses as separate step efore building
ape4 8y ago
JSON seems to verbose for this
- mistrial9 8y ago
  the criticism above was that make alone is not machine-understandable, therefore an IDE or other toolchain tooling parts cannot assist. JSON output (and the assumed contents of the JSON structures) enable another computer program to understand something about the build, and also is not terrible for humans to read.
kartikkumar 8y ago
Interesting. I've been messing for a while with my own boilerplate C++ project [0], since I got sick of having to recreate the CMake set up for every app I created. It's taken a lot of CMake magic to get it working and I'm still not totally happy with the config using ExternalProject_add to automagically deal with dependencies that aren't present. I've been evaluating Hunter [1] and wondering whether to step over. If I understand correctly, the big advantage of Bake is that it completely replaces CMake for dependency management (at least that's what I take away from the readme)? [0] https://github.com/kartikkumar/cppbase https://github.com/kartikkumar/cppbase [1] https://github.com/ruslo/hunter https://github.com/ruslo/hunter
- humanrebar 8y ago
  Avoid ExternalProject_Add. You're better off using 'find_package', 'add_subdirectory', 'pkg_check_modules', or Conan depending on where your dependency comes from. In my opinion, CMake is best as a (meta)build system, leaving packaging details to a different layer.
  - kartikkumar 8y ago
    I use ExternalProject_Add of building external dependencies from source, like this: https://github.com/kartikkumar/cppbase/blob/master/Dependencies.cmake https://github.com/kartikkumar/cppbase/blob/master/Dependenc...
- ajmmertens 8y ago
  Yes, that is correct. Bake can find dependencies regardless of where the dependency's source code is. You also don't need to first install your project before it can be used as a dependency, building is enough. A big difference with CMake is that bake stores package binaries, include files and metadata in a $HOME/bake directory. It won't actually install anything to /usr/local (or equivalent), unless you explicitly tell it to. Users typically first build everything to their $HOME/bake folder, and then when they want to make it available for all users, copy the contents of that folder to /opt when distributing the project.
kstenerud 8y ago
How do you run unit tests in a bake project?
- ajmmertens 8y ago
  I am currently working to reintegrate a feature in bake (from before the fork) that will allow you to run unit tests on discovered projects. Stay tuned ...
kstenerud 8y ago
https://www.github.com/SanderMertens/bake https://www.github.com/SanderMertens/bake is a fork of https://github.com/cortoproject/bake.. https://github.com/cortoproject/bake... Is there any reason why the title link doesn't go to the original?
- ricardobeat 8y ago
  Around halfway through the README it explains its origins in the Corto framework and how it has been extracted as an independent project.
radarsat1 8y ago
Cue the pull requests adding yet another build system to my projects..
- ajmmertens 8y ago
  No need, bake can link with your projects like it can link with any other C/C++ library: https://github.com/SanderMertens/bake#can-i-link-with-non-bake-libraries https://github.com/SanderMertens/bake#can-i-link-with-non-ba...
ricardobeat 8y ago
Was YAML, CSON or some other format considered for config? JSON is not exactly human-friendly.
- richardwhiuk 8y ago
  Toml would be the best choice IMO
  - crdoconnor 8y ago
    TOML is syntactically noisy and about 50% more verbose.
    - cyphar 8y ago
      I'm not sure how [general] foo = bar is 50% more verbose than { "general": { "foo": "bar" } } But also it's significantly more human-readable (and critically, it's much more human-writable).
      - crdoconnor 8y ago
        It starts to get more verbose when you have more keys and deeper indentation since the whole hierarchy is repeated for each key e.g. [general.foo.bar.bar]. JSON wasn't intended for maximal human readability/writability like CSON/YAML were. It was intended first and foremost as a simple data transmission format.
        richardwhiuk 8y ago
        Large hierarchies are always difficult in plain text formats. I'd argue if you need the user programming the config to understand a large hierarchy then you've already got a problem.
        crdoconnor 8y ago
        By large I mean two/three levels and above. Nothing's perfect but YAML does that fairly well (e.g. ansible playbooks) TOML handles anything three levels or above in a less readable way than indented JSON (which doesn't even prioritize readability). It looks find provided you're only dealing with tiny ultra simple config files.
drasah 8y ago
You have to visit Maktabtk site to get all about theoretical framework in research plan you need to use in scientific research https://www.maktabtk.com/ https://www.maktabtk.com/ https://www.maktabtk.com/service/7/%D8%A5%D8%B9%D8%AF%D8%A7%D8%AF-%D8%A7%D9%84%D8%A5%D8%B7%D8%A7%D8%B1-%D8%A7%D9%84%D9%86%D8%B8%D8%B1%D9%8A.html https://www.maktabtk.com/service/7/%D8%A5%D8%B9%D8%AF%D8%A7%...
humanrebar 8y ago
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.
adev_ 8y ago
Cool. One more "new" build system after Meson (https://mesonbuild.com/ https://mesonbuild.com/), Scons (https://scons.org/ https://scons.org/), "Modern" CMake (https://cmake.org/ https://cmake.org/), Waf (https://waf.io/ https://waf.io/), qmake (http://doc.qt.io/qt-5/qmake-language.html http://doc.qt.io/qt-5/qmake-language.html), b2 (https://boostorg.github.io/build/tutorial.html https://boostorg.github.io/build/tutorial.html), Jam (https://www.boost.org/doc/libs/1_31_0/tools/build/jam_src/index.html https://www.boost.org/doc/libs/1_31_0/tools/build/jam_src/in...), premake (https://premake.github.io/ https://premake.github.io/), build2 (https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#preface https://build2.org/build2-toolchain/doc/build2-toolchain-int...), GYP(https://gyp.gsrc.io/ https://gyp.gsrc.io/), vcpkg (https://github.com/Microsoft/vcpkg https://github.com/Microsoft/vcpkg), Bucks (https://buckbuild.com/ https://buckbuild.com/), Bazel (https://github.com/bazelbuild https://github.com/bazelbuild) and autotools. It is true that one more was really needed. One more that has the genetic disease of : - Trying of being "purely declarative", a thing that at least 4 build system already tried and failed as soon as portability and configuration kicks into the picture. - Try to merge the concept of build system and package manager: A terrible idea for anything touching C/C++ for reasons discussed 20 times already. - Use its own syntax and config, because that is really what every developer want to do: Learn how to use a build system zoo for every component they want to use. Well done guys. Edit: I forgot some...
- Hendrikto 8y ago
  > for reasons discussed 20 times Could you provide some pointers, ideally a link?
  - adev_ 8y ago
    It was discussed for Meson when they included the "subproject" support as major issue for all the GNOME components for most linux distributions. There is some note here https://mesonbuild.com/Subprojects.html https://mesonbuild.com/Subprojects.html or here https://blogs.gnome.org/ignatenko/2015/05/21/meson-and-3rd-party-dependencies-only-one-correct-way/ https://blogs.gnome.org/ignatenko/2015/05/21/meson-and-3rd-p... Or more recently with Bazel that do the same but arrives to do it much worst: https://github.com/tensorflow/tensorflow/issues/6210 https://github.com/tensorflow/tensorflow/issues/6210 or https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/ https://archive.fosdem.org/2018/schedule/event/how_to_make_p... Same with Hunter and CMake External: https://github.com/ruslo/hunter/issues/296 https://github.com/ruslo/hunter/issues/296 I have managed an ecosystem of ~250 software for a team in the past. Software bundling their dependencies are the worst and any package manager will tell you that. Due to diamond dependency problem, they explode as soon as you try to integrate them into a bigger picture... It is a pure waste of time for every packager. And I am not even speaking of bug fixes update on dependencies, security update, environment without Internet access or anything like that.... because dependency bundling prevent or make hard all of that.

132 points by ajmmertens 8y ago

Is this related to Bakefiles? There's already something with that name. [1] [1] https://bakefile.org/ https://bakefile.org/

naniwaduni 8y ago
It's like the second name everyone comes up with. There are at least five build systems (or adjacent) named bake. Probably a few orders of magnitude more.
- deleted 8y ago
  [deleted]
metahost 8y ago
No, they seem unrelated.

saagarjha 8y ago

Interesting README: > The Dutch IRS has a catchy slogan, which goes like this: "Leuker kunnen we 't niet maken, wel makkelijker". Roughly translated, this means: "We can't make it more fun, but we can make it easier". If only filing taxes in the U.S. was like this… > Bake does not collect any information when you clone, build or publish projects. It's sad that this needs to be said.

cbcoutinho 8y ago
I moved to the Netherlands five years ago from the US - dealing with the tax agency here is such a breeze compared to the IRS.
- kartikkumar 8y ago
  Having lived in a bunch of countries over the past decade, it's only when I moved back home to NL that I fully appreciated how easy things are. Firstly, digital filing is the norm and for "simple" returns, just works. Secondly, if you ever have a question, you can just call the tax authority on their free phone number, and pretty much ask them anything related to individual or business tax returns.
  - mattkrause 8y ago
    I once had to call the IRS for something and it also “worked”. The wait time was pretty reasonable (5 min or so), the person I spoke with was polite, knowledgeable, and actually resolved the problem on the first try. It was heads and shoulders above most interactions I’ve had with with ISPs, big banks, and the like, where you get transferred around between departments that don’t seem particularly interested in helping you out....
- IshKebab 8y ago
  In the UK most people don't have to file taxes at all. Can't get easier than that.
  - geezerjay 8y ago
    How much is that due to the UK being a surveillance state?
    - IshKebab 8y ago
      None.
Teknoman117 8y ago
The worst part is that a large portion of the push back against improving the tax system here in the US is all the tax software companies. Intuit (and H&R Block) spend millions every year lobbying against tax code simplifications or at least simplifying how you interact with the IRS.
- geezerjay 8y ago
  Someone has to keep breaking windows for the good of the economy.

bake 8y ago

I'm honored

j1elo 8y ago
So what I understood from the readme is that all dependencies would also need to be configured around Bake, is that correct? I guess this will be the main chicken and egg problem, as with other build tools, given the variety of tools that exist and are used across different libraries. Although I've found that autotools tends to be a common denominator in most of the ones I've had to work with... A minor detail: the table under Template Functions is not properly formatted and Github doesn't render it as a table.
- ajmmertens 8y ago
  Thanks for finding the formatting issue, fixed it! You don't need to specify all dependencies "the bake way". If you want to link with a non-bake C library (like pthread or dl), you can configure it like shown here: https://github.com/SanderMertens/bake#can-i-link-with-non-bake-libraries https://github.com/SanderMertens/bake#can-i-link-with-non-ba... It is also possible to wrap existing libraries in bake projects. This section of the README describes how: https://github.com/SanderMertens/bake/blob/master/README.md#integrating-non-bake-projects https://github.com/SanderMertens/bake/blob/master/README.md#...
  - j1elo 8y ago
    Oh sorry, I hadn't read the whole document. Thanks for the link, now I'll finish reading it!

Ericson2314 8y ago

My two favorites parts: - always cross: native builds are just build=host builds. - preprocesses as separate step efore building

ape4 8y ago

JSON seems to verbose for this

mistrial9 8y ago
the criticism above was that make alone is not machine-understandable, therefore an IDE or other toolchain tooling parts cannot assist. JSON output (and the assumed contents of the JSON structures) enable another computer program to understand something about the build, and also is not terrible for humans to read.

kartikkumar 8y ago

Interesting. I've been messing for a while with my own boilerplate C++ project [0], since I got sick of having to recreate the CMake set up for every app I created. It's taken a lot of CMake magic to get it working and I'm still not totally happy with the config using ExternalProject_add to automagically deal with dependencies that aren't present. I've been evaluating Hunter [1] and wondering whether to step over. If I understand correctly, the big advantage of Bake is that it completely replaces CMake for dependency management (at least that's what I take away from the readme)? [0] https://github.com/kartikkumar/cppbase https://github.com/kartikkumar/cppbase [1] https://github.com/ruslo/hunter https://github.com/ruslo/hunter

humanrebar 8y ago
Avoid ExternalProject_Add. You're better off using 'find_package', 'add_subdirectory', 'pkg_check_modules', or Conan depending on where your dependency comes from. In my opinion, CMake is best as a (meta)build system, leaving packaging details to a different layer.
- kartikkumar 8y ago
  I use ExternalProject_Add of building external dependencies from source, like this: https://github.com/kartikkumar/cppbase/blob/master/Dependencies.cmake https://github.com/kartikkumar/cppbase/blob/master/Dependenc...
ajmmertens 8y ago
Yes, that is correct. Bake can find dependencies regardless of where the dependency's source code is. You also don't need to first install your project before it can be used as a dependency, building is enough. A big difference with CMake is that bake stores package binaries, include files and metadata in a $HOME/bake directory. It won't actually install anything to /usr/local (or equivalent), unless you explicitly tell it to. Users typically first build everything to their $HOME/bake folder, and then when they want to make it available for all users, copy the contents of that folder to /opt when distributing the project.

kstenerud 8y ago

How do you run unit tests in a bake project?

ajmmertens 8y ago
I am currently working to reintegrate a feature in bake (from before the fork) that will allow you to run unit tests on discovered projects. Stay tuned ...

kstenerud 8y ago

https://www.github.com/SanderMertens/bake https://www.github.com/SanderMertens/bake is a fork of https://github.com/cortoproject/bake.. https://github.com/cortoproject/bake... Is there any reason why the title link doesn't go to the original?

ricardobeat 8y ago
Around halfway through the README it explains its origins in the Corto framework and how it has been extracted as an independent project.

radarsat1 8y ago

Cue the pull requests adding yet another build system to my projects..

ajmmertens 8y ago
No need, bake can link with your projects like it can link with any other C/C++ library: https://github.com/SanderMertens/bake#can-i-link-with-non-bake-libraries https://github.com/SanderMertens/bake#can-i-link-with-non-ba...

ricardobeat 8y ago

Was YAML, CSON or some other format considered for config? JSON is not exactly human-friendly.

richardwhiuk 8y ago
Toml would be the best choice IMO
- crdoconnor 8y ago
  TOML is syntactically noisy and about 50% more verbose.
  - cyphar 8y ago
    I'm not sure how [general] foo = bar is 50% more verbose than { "general": { "foo": "bar" } } But also it's significantly more human-readable (and critically, it's much more human-writable).
    - crdoconnor 8y ago
      It starts to get more verbose when you have more keys and deeper indentation since the whole hierarchy is repeated for each key e.g. [general.foo.bar.bar]. JSON wasn't intended for maximal human readability/writability like CSON/YAML were. It was intended first and foremost as a simple data transmission format.
      - richardwhiuk 8y ago
        Large hierarchies are always difficult in plain text formats. I'd argue if you need the user programming the config to understand a large hierarchy then you've already got a problem.
        crdoconnor 8y ago
        By large I mean two/three levels and above. Nothing's perfect but YAML does that fairly well (e.g. ansible playbooks) TOML handles anything three levels or above in a less readable way than indented JSON (which doesn't even prioritize readability). It looks find provided you're only dealing with tiny ultra simple config files.

drasah 8y ago

You have to visit Maktabtk site to get all about theoretical framework in research plan you need to use in scientific research https://www.maktabtk.com/ https://www.maktabtk.com/ https://www.maktabtk.com/service/7/%D8%A5%D8%B9%D8%AF%D8%A7%D8%AF-%D8%A7%D9%84%D8%A5%D8%B7%D8%A7%D8%B1-%D8%A7%D9%84%D9%86%D8%B8%D8%B1%D9%8A.html https://www.maktabtk.com/service/7/%D8%A5%D8%B9%D8%AF%D8%A7%...

humanrebar 8y ago

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.

adev_ 8y ago

Cool. One more "new" build system after Meson (https://mesonbuild.com/ https://mesonbuild.com/), Scons (https://scons.org/ https://scons.org/), "Modern" CMake (https://cmake.org/ https://cmake.org/), Waf (https://waf.io/ https://waf.io/), qmake (http://doc.qt.io/qt-5/qmake-language.html http://doc.qt.io/qt-5/qmake-language.html), b2 (https://boostorg.github.io/build/tutorial.html https://boostorg.github.io/build/tutorial.html), Jam (https://www.boost.org/doc/libs/1_31_0/tools/build/jam_src/index.html https://www.boost.org/doc/libs/1_31_0/tools/build/jam_src/in...), premake (https://premake.github.io/ https://premake.github.io/), build2 (https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#preface https://build2.org/build2-toolchain/doc/build2-toolchain-int...), GYP(https://gyp.gsrc.io/ https://gyp.gsrc.io/), vcpkg (https://github.com/Microsoft/vcpkg https://github.com/Microsoft/vcpkg), Bucks (https://buckbuild.com/ https://buckbuild.com/), Bazel (https://github.com/bazelbuild https://github.com/bazelbuild) and autotools. It is true that one more was really needed. One more that has the genetic disease of : - Trying of being "purely declarative", a thing that at least 4 build system already tried and failed as soon as portability and configuration kicks into the picture. - Try to merge the concept of build system and package manager: A terrible idea for anything touching C/C++ for reasons discussed 20 times already. - Use its own syntax and config, because that is really what every developer want to do: Learn how to use a build system zoo for every component they want to use. Well done guys. Edit: I forgot some...

Hendrikto 8y ago
> for reasons discussed 20 times Could you provide some pointers, ideally a link?
- adev_ 8y ago
  It was discussed for Meson when they included the "subproject" support as major issue for all the GNOME components for most linux distributions. There is some note here https://mesonbuild.com/Subprojects.html https://mesonbuild.com/Subprojects.html or here https://blogs.gnome.org/ignatenko/2015/05/21/meson-and-3rd-party-dependencies-only-one-correct-way/ https://blogs.gnome.org/ignatenko/2015/05/21/meson-and-3rd-p... Or more recently with Bazel that do the same but arrives to do it much worst: https://github.com/tensorflow/tensorflow/issues/6210 https://github.com/tensorflow/tensorflow/issues/6210 or https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/ https://archive.fosdem.org/2018/schedule/event/how_to_make_p... Same with Hunter and CMake External: https://github.com/ruslo/hunter/issues/296 https://github.com/ruslo/hunter/issues/296 I have managed an ecosystem of ~250 software for a team in the past. Software bundling their dependencies are the worst and any package manager will tell you that. Due to diamond dependency problem, they explode as soon as you try to integrate them into a bigger picture... It is a pure waste of time for every packager. And I am not even speaking of bug fixes update on dependencies, security update, environment without Internet access or anything like that.... because dependency bundling prevent or make hard all of that.