16 ms·

I understand being upset with Apple at this arbitrary cutoff. But can we also talk about why a recompile isn’t as simple as opening the old project and hitting

I understand being upset with Apple at this arbitrary cutoff. But can we also talk about why a recompile isn’t as simple as opening the old project and hitting “compile”? I work on a large project (millions of lines of code), which has been in continuous development for 20 years. Every new compiler or IDE release results in us having to dedicate at least one engineer full time for a few days to get our project compiling again with the new tools before the team can switch over. That’s a project that previously compiled with no errors or warnings (because we set warnings are errors to true) suddenly can’t build. It’s ridiculous! I can’t imagine throwing something like Unity in on top of that.

ploxiln 4y ago
-Werror is your mistake here. You can still fix warnings when you see them with a new compiler, without using -Werror to cause complete build failures except with a specific set of specially accommodated compiler versions.
- thewebcount 4y ago
  LOL! If only. We started out that way and nobody fixed their warnings. The only way to make it happen was to make it so they couldn’t compile with warnings. (And we do selectively turn off certain warnings that aren’t helpful and give false positives.) To be clear, I’m not talking about having to clean up a few new warnings with a new compiler release. That’s fine and probably a good thing. We really have to have one of our top engineers dive into it for several days to get things in shape. It just seems really weird to me.
  - erik_seaberg 4y ago
    A code review tool should display warnings, and reviewers should expect fixes for real problems that show up that way (and suppression of false positives).
SilasX 4y ago
I was really upset when I ran into this problem with Docker. Like, I thought the whole point of virtualization was that, no matter how old it is, it will Just Work, so long as the virtualization software works, and it has enough resources. It’s supposed to sidestep the problem having to constantly patch everything that might have changed since. Then one day, our startup brought some new employees on, who read the README and ran the indicated Docker command … and it failed with a mysterious bug requiring dev resources to debug! The exact thing you try to avoid by freezing the machine environment. It turned out that Docker had silently pushed a backward-incompatible change in the format of docker-compose YAML files.
- seba_dos1 4y ago
  That's not what containerization is about as can be easily demonstrated by simply running your container on a kernel that's built without some config option you rely on.
  - SilasX 4y ago
    Wait, what? So this isn’t a problem because you can just make a container for your containers that preserves the original API? Then what do you depend on for that container? It’s like Office Space, “what would you say it is you do here?”
    - hedora 4y ago
      Containers standardize user space, and let processes think they're listening on ports that are already taken. They do some resource isolation, and provide similar security guarantees as painting the back of your laptop with snake oil. They don't help at all with kernel API drift, and barely help with libc drift.
      - SilasX 4y ago
        I didn’t say anything about security guarantees. Where did that come from? You’re saying that using a container — which defines a specific version of an OS — shouldn’t protect against differences between that version and a new OS version? And shouldn’t save any effort whatsoever in reproducing the environment in which I got code working? The sole purpose is so that I can leave an app configured to talk to port 8000 even though my machine is already using port 8000? That feels like it falls short of the conventional case for virtualization or containerization.
deleted 4y ago
[deleted]
verelo 4y ago
Sometimes recompiling into a new version of Xcode is required and that can result in very painful edits. While locally you can do whatever, apple often requires you to be using a very recent sdk (sometimes for good reasons like OS security of privacy changes)
kazinator 4y ago
If you set warnings to errors, and upgrade your compiler from time to time, you're asking the compiler people to help find hitherto undiscovered issues in your code using the latest diagnostic tools that they have come up with. If you don't want to be informed, then don't do that. But those issues could be real bugs. For instance, one fine day GCC got the ability to diagnose situations when the indentation of an nested if statement is deceptive compared to the actual precedence of the clauses. So if someone had warnings as errors, and had such a statement, then their build stopped. If that was a real bug, they were grateful.
- gnubison 4y ago
  Please, please, please don’t do this for end-user compiled software, because someday they’re going to be using a more modern compiler than you and their build is going to break because of new warnings that you couldn’t anticipate.
  - lupire 4y ago
    When do end users compile software but don't want to fix bugs?
    - kadoban 4y ago
      When the bug they're being forced to fix does not affect them. This can happen when they want to make some other change, or maybe they don't even need changes, they just need a build that doesn't exist.
    - ploxiln 4y ago
      New warnings usually do not indicate real bugs. Sometimes they do, but usually they are false positives. -Werror causing a build to fail is strictly worse than the alternative (working roughly as well as before, sometimes slightly better or worse due to new optimizations). This is the direct cause of "software decay" here. The software would not "decay" nearly as much without -Werror. Often a technical linux user will want to download a source tarball for a particular version of a utility or program, and build it on or for a particular linux distro they're using. They usually do not want ad-hoc modifications done to the source of all the specific utility versions they compile for their system this way.
cpeterso 4y ago
Someone replied to the original tweet with an example of their iOS dev experience: Boss wants to change our iOS game icon. Changing icon requires a new build. A new build requires iPhone X support. iPhone X build target requires Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old Unity3D. Upgrading Unity breaks build. https://twitter.com/aaefiikmnnnr/status/931222777301835782?s=21&t=o3e4ZiIVwowtnd2yIQ6CZQ https://twitter.com/aaefiikmnnnr/status/931222777301835782?s...
- st3fan 4y ago
  It is already very time consuming to stay up to date with Apples ecosystem. Swift evolves. Xcode changes. The runtime. The App Store. The APIs evolve. SwiftUI is radically different every year. Throw something like Unity in the mix and now you have even more things to keep up to date. You can say well that is just nonsense. My app is finished. But is it really? what if you actually need to do a critical bug fix. Or something to be compatible with new hardware? There is no simple answer here. But one thing I’ve learned is that staying as “standard” as possible is a huge huge advantage. Apples upward path is mostly manageable.
- arinlen 4y ago
  > Boss wants to change our iOS game icon. Changing icon requires a new build. A new build requires iPhone X support. iPhone X build target requires Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old Unity3D. Upgrading Unity breaks build. * The iPhone X was released on 2018. * Xcode 9.0 was released on 2017, and 9.4.1 (last release) on 2018. * macOS 10.12 was released on 2016. I'm sorry to say, but this sort of setup does not reflect well on anyone working on the project. Apple's call out should be considered a wakeup call. Also, doesn't Xcode 9 only support iOS releases up to iOS 11? The global market of all iOS versions lower than iOS 11 should lie in the lower single digits.
  - michaelt 4y ago
    You do realise the tweet you're replying to is from 2017?
  - maccard 4y ago

ploxiln 4y ago

-Werror is your mistake here. You can still fix warnings when you see them with a new compiler, without using -Werror to cause complete build failures except with a specific set of specially accommodated compiler versions.

thewebcount 4y ago
LOL! If only. We started out that way and nobody fixed their warnings. The only way to make it happen was to make it so they couldn’t compile with warnings. (And we do selectively turn off certain warnings that aren’t helpful and give false positives.) To be clear, I’m not talking about having to clean up a few new warnings with a new compiler release. That’s fine and probably a good thing. We really have to have one of our top engineers dive into it for several days to get things in shape. It just seems really weird to me.
- erik_seaberg 4y ago
  A code review tool should display warnings, and reviewers should expect fixes for real problems that show up that way (and suppression of false positives).

SilasX 4y ago

I was really upset when I ran into this problem with Docker. Like, I thought the whole point of virtualization was that, no matter how old it is, it will Just Work, so long as the virtualization software works, and it has enough resources. It’s supposed to sidestep the problem having to constantly patch everything that might have changed since. Then one day, our startup brought some new employees on, who read the README and ran the indicated Docker command … and it failed with a mysterious bug requiring dev resources to debug! The exact thing you try to avoid by freezing the machine environment. It turned out that Docker had silently pushed a backward-incompatible change in the format of docker-compose YAML files.

seba_dos1 4y ago
That's not what containerization is about as can be easily demonstrated by simply running your container on a kernel that's built without some config option you rely on.
- SilasX 4y ago
  Wait, what? So this isn’t a problem because you can just make a container for your containers that preserves the original API? Then what do you depend on for that container? It’s like Office Space, “what would you say it is you do here?”
  - hedora 4y ago
    Containers standardize user space, and let processes think they're listening on ports that are already taken. They do some resource isolation, and provide similar security guarantees as painting the back of your laptop with snake oil. They don't help at all with kernel API drift, and barely help with libc drift.
    - SilasX 4y ago
      I didn’t say anything about security guarantees. Where did that come from? You’re saying that using a container — which defines a specific version of an OS — shouldn’t protect against differences between that version and a new OS version? And shouldn’t save any effort whatsoever in reproducing the environment in which I got code working? The sole purpose is so that I can leave an app configured to talk to port 8000 even though my machine is already using port 8000? That feels like it falls short of the conventional case for virtualization or containerization.

deleted 4y ago

[deleted]

verelo 4y ago

Sometimes recompiling into a new version of Xcode is required and that can result in very painful edits. While locally you can do whatever, apple often requires you to be using a very recent sdk (sometimes for good reasons like OS security of privacy changes)

kazinator 4y ago

If you set warnings to errors, and upgrade your compiler from time to time, you're asking the compiler people to help find hitherto undiscovered issues in your code using the latest diagnostic tools that they have come up with. If you don't want to be informed, then don't do that. But those issues could be real bugs. For instance, one fine day GCC got the ability to diagnose situations when the indentation of an nested if statement is deceptive compared to the actual precedence of the clauses. So if someone had warnings as errors, and had such a statement, then their build stopped. If that was a real bug, they were grateful.

gnubison 4y ago
Please, please, please don’t do this for end-user compiled software, because someday they’re going to be using a more modern compiler than you and their build is going to break because of new warnings that you couldn’t anticipate.
- lupire 4y ago
  When do end users compile software but don't want to fix bugs?
  - kadoban 4y ago
    When the bug they're being forced to fix does not affect them. This can happen when they want to make some other change, or maybe they don't even need changes, they just need a build that doesn't exist.
  - ploxiln 4y ago
    New warnings usually do not indicate real bugs. Sometimes they do, but usually they are false positives. -Werror causing a build to fail is strictly worse than the alternative (working roughly as well as before, sometimes slightly better or worse due to new optimizations). This is the direct cause of "software decay" here. The software would not "decay" nearly as much without -Werror. Often a technical linux user will want to download a source tarball for a particular version of a utility or program, and build it on or for a particular linux distro they're using. They usually do not want ad-hoc modifications done to the source of all the specific utility versions they compile for their system this way.

cpeterso 4y ago

Someone replied to the original tweet with an example of their iOS dev experience: Boss wants to change our iOS game icon. Changing icon requires a new build. A new build requires iPhone X support. iPhone X build target requires Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old Unity3D. Upgrading Unity breaks build. https://twitter.com/aaefiikmnnnr/status/931222777301835782?s=21&t=o3e4ZiIVwowtnd2yIQ6CZQ https://twitter.com/aaefiikmnnnr/status/931222777301835782?s...

st3fan 4y ago
It is already very time consuming to stay up to date with Apples ecosystem. Swift evolves. Xcode changes. The runtime. The App Store. The APIs evolve. SwiftUI is radically different every year. Throw something like Unity in the mix and now you have even more things to keep up to date. You can say well that is just nonsense. My app is finished. But is it really? what if you actually need to do a critical bug fix. Or something to be compatible with new hardware? There is no simple answer here. But one thing I’ve learned is that staying as “standard” as possible is a huge huge advantage. Apples upward path is mostly manageable.
arinlen 4y ago
> Boss wants to change our iOS game icon. Changing icon requires a new build. A new build requires iPhone X support. iPhone X build target requires Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old Unity3D. Upgrading Unity breaks build. * The iPhone X was released on 2018. * Xcode 9.0 was released on 2017, and 9.4.1 (last release) on 2018. * macOS 10.12 was released on 2016. I'm sorry to say, but this sort of setup does not reflect well on anyone working on the project. Apple's call out should be considered a wakeup call. Also, doesn't Xcode 9 only support iOS releases up to iOS 11? The global market of all iOS versions lower than iOS 11 should lie in the lower single digits.
- michaelt 4y ago
  You do realise the tweet you're replying to is from 2017?
- maccard 4y ago