3 ms·

89 libraries is a lot. Even the most complex project I work on has just 20. The list you gave seems somewhat reasonable, but I'm willing to bet that the long ta

89 libraries is a lot. Even the most complex project I work on has just 20. The list you gave seems somewhat reasonable, but I'm willing to bet that the long tail of stuff you didn't mention includes a lot of more trivial dependencies. I don't know your project, but I imagine that you ought to redefine your scope to avoid introducing a need on complex dependencies. Simpler software is more robust, more maintainable, and often gets the job done better - but it's more difficult to make. In any case, I'm mainly criticisng the typical JavaScript, Ruby, etc project, with their giant pile of node_modules or whatever the case may be. It can easily get out of hand with other projects, too, especially in languages which encourage over-engineering and over-abstracting like Rust or C++ (let me guess: yours is the latter?).

akkartik 7y ago
As a trivial example, I spent a couple of hours last night pruning stuff I didn't need from one of my text editor plugins (https://github.com/mhinz/vim-signify https://github.com/mhinz/vim-signify). I was able to take it down from 1400 lines to sub-300 lines. And in the process it became a lot clearer precisely what the algorithmic core of the library was. A valuable learning experience. vim-signify was 800 lines large back in 2014 when I first started using it. How much of the stuff added since mattered to me? Almost nothing. These are the costs we all take on -- death by a thousand cuts -- when we blindly import dependencies.
PaulDavisThe1st 7y ago
https://nightly.ardour.org/list.php#build_deps https://nightly.ardour.org/list.php#build_deps C++ (with a tiny bit of assembler). Most of our dependencies arise from our choice to use GTK, but there's a fair number that do not. I wouldn't call any of them trivial dependencies. Edit: on the order of a dozen of the deps are actually requirements for the build system of libs we depend on (e.g. autotools nonsense), but from a practical perspective, they are dependencies that have to be satisfied if you want to build Ardour completely from scratch (by which we mean, alternately, a Linux system with only libc, libstdc++ and X, or a new macOS install).
- ddevault 7y ago
  Build deps aren't free, but have different constraints and effects. Anyway, if this is your full dependency tree - with transitive dependencies included - this is fairly reasonable. I reckon Boost doesn't need to be there, and you're probably well past the point of diminishing returns with GTK+ and a UI like yours, but otherwise this seems reasonable to me. You should also consider moving on from autotools by now, I recommend Meson as a replacement. These kinds of questions - is autotools still a good choice? Do we really need Boost? Is GTK+ doing us any favors? Answering these is the "careful keeping of your dependency graph small and conservative" that I am referring to.
  - PaulDavisThe1st 7y ago
    Yes, this is a fully transitive deps list. I mentioned autotools as part of the build system of some of our dependencies. We abandoned it ourselves in disgust many years ago (in favor of waf; meson may be in our future). Boost is critical for us because we aim for compatibility (and for macOS that means buildability) on systems only reaching C++98, meaning that boost fills in large parts of the then-missing std:: namespace (such as shared_ptr<>). We will move to C++11 after our 6.0 release, but boost still provides several other very useful bits of functionality. GTK+ remains useful even as we slowly move away from it, and there remains the big four (text entry, file browsing, treeviews and menus) that will be a huge effort to reimplement. Our goal is to eventually depend only upon GDK (i.e. a thin window system wrapper), but I doubt that we will ever reach that goal.
    - ddevault 7y ago
      1998 was 22 years ago. At some point we've gotta let it go. And I'm not going to argue about Boost, but it'll suffice to say that I passionately hate C++ and Boost is a big part of why. That Ardour is a C++ project has a lot to do with its sprawling complexity, these are often correlated (which is why I guessed C++ from your earlier description). Also, I would definitely recommend looking into Meson instead of waf, having used both. Anyway, I think we have reached something resembling an understanding. Your dependencies are fairly reasonable, but there's room to and reason to cull them down a bit.

akkartik 7y ago

As a trivial example, I spent a couple of hours last night pruning stuff I didn't need from one of my text editor plugins (https://github.com/mhinz/vim-signify https://github.com/mhinz/vim-signify). I was able to take it down from 1400 lines to sub-300 lines. And in the process it became a lot clearer precisely what the algorithmic core of the library was. A valuable learning experience. vim-signify was 800 lines large back in 2014 when I first started using it. How much of the stuff added since mattered to me? Almost nothing. These are the costs we all take on -- death by a thousand cuts -- when we blindly import dependencies.

PaulDavisThe1st 7y ago

https://nightly.ardour.org/list.php#build_deps https://nightly.ardour.org/list.php#build_deps C++ (with a tiny bit of assembler). Most of our dependencies arise from our choice to use GTK, but there's a fair number that do not. I wouldn't call any of them trivial dependencies. Edit: on the order of a dozen of the deps are actually requirements for the build system of libs we depend on (e.g. autotools nonsense), but from a practical perspective, they are dependencies that have to be satisfied if you want to build Ardour completely from scratch (by which we mean, alternately, a Linux system with only libc, libstdc++ and X, or a new macOS install).

ddevault 7y ago
Build deps aren't free, but have different constraints and effects. Anyway, if this is your full dependency tree - with transitive dependencies included - this is fairly reasonable. I reckon Boost doesn't need to be there, and you're probably well past the point of diminishing returns with GTK+ and a UI like yours, but otherwise this seems reasonable to me. You should also consider moving on from autotools by now, I recommend Meson as a replacement. These kinds of questions - is autotools still a good choice? Do we really need Boost? Is GTK+ doing us any favors? Answering these is the "careful keeping of your dependency graph small and conservative" that I am referring to.
- PaulDavisThe1st 7y ago
  Yes, this is a fully transitive deps list. I mentioned autotools as part of the build system of some of our dependencies. We abandoned it ourselves in disgust many years ago (in favor of waf; meson may be in our future). Boost is critical for us because we aim for compatibility (and for macOS that means buildability) on systems only reaching C++98, meaning that boost fills in large parts of the then-missing std:: namespace (such as shared_ptr<>). We will move to C++11 after our 6.0 release, but boost still provides several other very useful bits of functionality. GTK+ remains useful even as we slowly move away from it, and there remains the big four (text entry, file browsing, treeviews and menus) that will be a huge effort to reimplement. Our goal is to eventually depend only upon GDK (i.e. a thin window system wrapper), but I doubt that we will ever reach that goal.
  - ddevault 7y ago
    1998 was 22 years ago. At some point we've gotta let it go. And I'm not going to argue about Boost, but it'll suffice to say that I passionately hate C++ and Boost is a big part of why. That Ardour is a C++ project has a lot to do with its sprawling complexity, these are often correlated (which is why I guessed C++ from your earlier description). Also, I would definitely recommend looking into Meson instead of waf, having used both. Anyway, I think we have reached something resembling an understanding. Your dependencies are fairly reasonable, but there's room to and reason to cull them down a bit.