3 ms·

This is why I think static bug checking and compiling should be two different tools. There is no reason to fail a build which used to run, even if it has bugs.

This is why I think static bug checking and compiling should be two different tools. There is no reason to fail a build which used to run, even if it has bugs. Doing all those checks at build time is slowing the build down too.

deleted 11y ago
[deleted]
plorkyeran 11y ago
Splitting static checks and compiling into separate tools will not prevent your builds from breaking when you update your tools if you have your build process deliberately configured to break whenever a new warning appears. GCC adding new warnings will not break your builds if you do not specifically ask for it to by using -Werror (or having your CI system reject any builds that produce warnings). At least with clang, -Weverything is not measurably slower than no warnings at all on any vaguely realistic code base.
- andrewchambers 11y ago
  A CI server is totally different to downloading a tarball and trying to run it. Using -Wall and -Werror in that situation is a terrible annoyance. With regard to speed, I just know that tcc is 10 times faster than gcc, and that makes a huge difference to me. Anything pointless is really irritating because I know how slow gcc is.
  - GFK_of_xmaspast 11y ago
    Then the issue is still with the app developers who ship a tgz with -Werror as the default. (Also I'd much rather have fast binaries slowly compiled than the opposite)
    - andrewchambers 11y ago
      Obviously the issue is with the app developers. That is why I am suggesting splitting static checking and compiling, so shit developers at least stand a chance of doing the right thing. (I would rather a fast compiler until I am ready to release a final product and then swap. I probably do more cross compiling and creating custom toolchains than you.)
      - GFK_of_xmaspast 11y ago
        If we're worried about lousy developers being lousy, then I think we should do the absolute opposite and make -Wall the default.

deleted 11y ago

[deleted]

plorkyeran 11y ago

Splitting static checks and compiling into separate tools will not prevent your builds from breaking when you update your tools if you have your build process deliberately configured to break whenever a new warning appears. GCC adding new warnings will not break your builds if you do not specifically ask for it to by using -Werror (or having your CI system reject any builds that produce warnings). At least with clang, -Weverything is not measurably slower than no warnings at all on any vaguely realistic code base.

andrewchambers 11y ago
A CI server is totally different to downloading a tarball and trying to run it. Using -Wall and -Werror in that situation is a terrible annoyance. With regard to speed, I just know that tcc is 10 times faster than gcc, and that makes a huge difference to me. Anything pointless is really irritating because I know how slow gcc is.
- GFK_of_xmaspast 11y ago
  Then the issue is still with the app developers who ship a tgz with -Werror as the default. (Also I'd much rather have fast binaries slowly compiled than the opposite)
  - andrewchambers 11y ago
    Obviously the issue is with the app developers. That is why I am suggesting splitting static checking and compiling, so shit developers at least stand a chance of doing the right thing. (I would rather a fast compiler until I am ready to release a final product and then swap. I probably do more cross compiling and creating custom toolchains than you.)
    - GFK_of_xmaspast 11y ago
      If we're worried about lousy developers being lousy, then I think we should do the absolute opposite and make -Wall the default.