Doug or Fariborz, can one of you comment on if you're fine with this in theory?
On Thu, Jan 29, 2015 at 3:33 PM, Nico Weber <[email protected]> wrote: > Ping. > > Another way to think about this warning is that it effectively ignores > declarations where the introduced version is higher than the deployment > version. > > On Thu, Jan 8, 2015 at 6:14 PM, Nico Weber <[email protected]> wrote: > >> Hi, >> >> the Mac OS X and iOS SDKs add new functions in new releases. Apple >> recommends using the newest SDK and setting the deployment target to >> whatever old OS version one wants to support, and only calling new >> functions after checking that they are available at runtime. >> >> In practice, we (Chromium) get this wrong. Others who support old OS X >> versions get this wrong too. Hence, we (Chromium) use a very old SDK and >> then manually declare new functions when we want to call them – this >> reduces the chance of us forgetting if they are available at runtime >> considerably, in practice. But using an old SDK has its problems – >> sometimes the frameworks check which SDK an app was linked against and only >> then activate bug fixes, and newer Xcodes don't ship include old SDKs. >> >> Ideally, we could use a new SDK but get a warning when we use a new API >> without a manual redeclaration – this protects us against new APIs the same >> way using an old SDK does without the drawbacks that this brings. >> >> The attached patch is a sketch how such a warning might work. How >> repulsive is this idea? Are there other approaches to this problem? If the >> basic idea is ok: Any comments on the implementation? >> >> I'm not sure who should look at this. dgregor, you wrote r128127 which >> looks in the same area. >> >> Thanks, >> Nico >> > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
