5 ms·

Because legacy. Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with propri

by phab 8y ago

Because legacy. Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with proprietary vendor tools. We can't change version numbering schemes because our packages already exist 'in the wild' and can't be changed mid-sequence without causing both technical and user pain. Fundamentally: the codebase has worked perfectly well this way for the last 20 years; what's the business case for changing it (at potentially significant cost) just to be compatible with XYZ new tool that everyone is rallying behind?

bdamm 8y ago
Usually this kind of refactor is something done as the very first task following the last release in a minor series and as the first step in a major new release. Going from version 7.4.32 to 8.0.0? Refactor that source tree, reformat all the code, and start over on the build toolchain! Best of all, make sure some junior dev does the actual checkin for the reformat. In all seriousness, I think this is the only way. Yeah you may have forever to deal with it cross patching but let's face it, for big lumbering code bases, perfect backwards compatibility in the source tree is usually the smallest of issues, and the benefit of using standard tools far outweighs the cost of occasionally reinterpreting back-patches (if they are even possible.)
- gpderetta 8y ago
  Some of these codebases have 10s of millions of lines if not more. Such a refactoring could take years.
  - bdamm 8y ago
    The benefit of using widely supported tooling is even greater for large codebases. Automated reformatting is easy, and moving code around isn't that hard if it's going hand in hand with a build system that supports it. Staying in the cooking pot of ever larger proprietary and exotic hacks is how organizations grind to a halt.
    - geezerjay 8y ago
      > The benefit of using widely supported tooling is even greater for large codebases. Your assertion really depends on your definition of "widely supported". Jumping from fad to fad, however, is only effective as a way to waste time. >Staying in the cooking pot of ever larger proprietary and exotic hacks is how organizations grind to a halt. Using established build systems for C++, whether autotools or even plain makefiles, ensures that the project doesn't suffer from bit rot and developers can focus om developing code instead of wasting their time trying out every flavor of the month. And do note that the main reason C++ hasn't adopted any official build system is that each and every flavour of the month ends up being very horrible and very hard to maintain. Yes, including CMake. If a build system is known for telling essentially all users that they are doing it wrong, that means the build system is the problem.
gpderetta 8y ago
> Because legacy Yes. And there are codebases that are going to outlive thee shiny tool of the month (or the decade, even).
lmm 8y ago
> Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with proprietary vendor tools. That hardcodes the source layout? I don't buy that a tool that's being sold for money would do that (precisely because there's no standardization in the C++ world; any tool that wants to have more than 1 customer will have to support more than 1 directory layout), and if the tools are internal then by definition you have the ability to make changes to them. > Fundamentally: the codebase has worked perfectly well this way for the last 20 years; what's the business case for changing it (at potentially significant cost) just to be compatible with XYZ new tool that everyone is rallying behind? Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling, don't be surprised when developers do that.
- delusional 8y ago
  > and if the tools are internal then by definition you have the ability to make changes to them. I happen to work in a shop with problems that look somewhat like this. We have a non-trivial amount of legacy code, that we just don't have the resources or motivation to fix. In those cases, we've found that the cohesion of doing it the same (wrong) way everywhere is easier to work with than doing it the new way in some places.
- phab 8y ago
  > I don't buy that a tool that's being sold for money would do that If you work with proprietory hardware (think FPGAs), if you want to use the hardware, you have to use proprietory vendor tools, whether you want to or not. > if the tools are internal then by definition you have the ability to make changes to them. This misses the point. Having the technical ability to modify the tool does not equal having the real-world-practicability, business-case-defendable ability to change the tool. > Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling The point is that in a 20 year, n-million line codebase, neither is "easy", and the pragmatic solution is to do neither.

by phab 8y ago

bdamm 8y ago

Usually this kind of refactor is something done as the very first task following the last release in a minor series and as the first step in a major new release. Going from version 7.4.32 to 8.0.0? Refactor that source tree, reformat all the code, and start over on the build toolchain! Best of all, make sure some junior dev does the actual checkin for the reformat. In all seriousness, I think this is the only way. Yeah you may have forever to deal with it cross patching but let's face it, for big lumbering code bases, perfect backwards compatibility in the source tree is usually the smallest of issues, and the benefit of using standard tools far outweighs the cost of occasionally reinterpreting back-patches (if they are even possible.)

gpderetta 8y ago
Some of these codebases have 10s of millions of lines if not more. Such a refactoring could take years.
- bdamm 8y ago
  The benefit of using widely supported tooling is even greater for large codebases. Automated reformatting is easy, and moving code around isn't that hard if it's going hand in hand with a build system that supports it. Staying in the cooking pot of ever larger proprietary and exotic hacks is how organizations grind to a halt.
  - geezerjay 8y ago
    > The benefit of using widely supported tooling is even greater for large codebases. Your assertion really depends on your definition of "widely supported". Jumping from fad to fad, however, is only effective as a way to waste time. >Staying in the cooking pot of ever larger proprietary and exotic hacks is how organizations grind to a halt. Using established build systems for C++, whether autotools or even plain makefiles, ensures that the project doesn't suffer from bit rot and developers can focus om developing code instead of wasting their time trying out every flavor of the month. And do note that the main reason C++ hasn't adopted any official build system is that each and every flavour of the month ends up being very horrible and very hard to maintain. Yes, including CMake. If a build system is known for telling essentially all users that they are doing it wrong, that means the build system is the problem.

gpderetta 8y ago

> Because legacy Yes. And there are codebases that are going to outlive thee shiny tool of the month (or the decade, even).

lmm 8y ago

> Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with proprietary vendor tools. That hardcodes the source layout? I don't buy that a tool that's being sold for money would do that (precisely because there's no standardization in the C++ world; any tool that wants to have more than 1 customer will have to support more than 1 directory layout), and if the tools are internal then by definition you have the ability to make changes to them. > Fundamentally: the codebase has worked perfectly well this way for the last 20 years; what's the business case for changing it (at potentially significant cost) just to be compatible with XYZ new tool that everyone is rallying behind? Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling, don't be surprised when developers do that.

delusional 8y ago
> and if the tools are internal then by definition you have the ability to make changes to them. I happen to work in a shop with problems that look somewhat like this. We have a non-trivial amount of legacy code, that we just don't have the resources or motivation to fix. In those cases, we've found that the cohesion of doing it the same (wrong) way everywhere is easier to work with than doing it the new way in some places.
phab 8y ago
> I don't buy that a tool that's being sold for money would do that If you work with proprietory hardware (think FPGAs), if you want to use the hardware, you have to use proprietory vendor tools, whether you want to or not. > if the tools are internal then by definition you have the ability to make changes to them. This misses the point. Having the technical ability to modify the tool does not equal having the real-world-practicability, business-case-defendable ability to change the tool. > Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling The point is that in a 20 year, n-million line codebase, neither is "easy", and the pragmatic solution is to do neither.