Compile device version check (which produces "ERROR: Device X requires API Level Y") not applied to Export Project, only Build Current Project and Build for Device

> And removing it breaking compatibility with eclipse (without any reason as everything run well).

The reason for deprecating things is usually that the maintainer(s) don't want to support them anymore.

Eclipse hasn't been supported for years, but we still see devs asking how they can download the Eclipse plugin. It doesn't help that the new dev FAQ still mentions Eclipse.

Since they decided not to use the "-c" option when building with the VS Code extension (I don't know the reason here, except maybe to simplify things? *), it makes sense that they would deprecate it. Perhaps there's also some sort of issue with that option that we're not aware of.

[*] I never understood why this option was available until I thought about the issue of multiple part numbers and CIQ versions per device (especially when there's separate part numbers for WW and APAC).

You are right -c was good but only for dev. And removing it breaking compatibility with eclipse (without any reason as everything run well).

The funny thing is that it's simple work around to this problem on condition there is compatibility in ciq.

For me, the trouble is treating the compilers options as error instead of warning. The only problem is the reusing them (e.g -c options) but reusing isn't a good idea, especially you can use 2 letters...

Here I'm understanding you to mean that you use the deprecated "-c" option (target API level) for old compilers, and it isn't available on the newest compiler, which causes a compiler error.

"the trouble is treating the compilers options as error instead of warning"

Yeah, there's no command line tool in the world that will give you a warning instead of an error when you use an unknown/unsupported option.

"-c" has been deprecated for a long time - since SDK 7.1.0, released almost a year ago.

I'm guessing the only reason it continued to exist was to avoid breaking Eclipse (which insists on asking the user to select a target API level and passing it on to the compiler). But Garmin dropped Eclipse support a long time ago so it's not surprising that "-c" is finally gone.

In fact if you used "-c" when it was deprecated, you would get a warning:

> WARNING: The command line option '-c' has been deprecated.

You are only getting an error now because "-c" is fully removed.

As a side note, I finally realized what "-c" was good for - if you selected a device which had different API versions for WW and APAC, you could use "-c" to select the lower API version. So it's actually too bad this option was removed. Now when we run a device in the sim, the WW part number with the higher CIQ version is always selected, and this has already led to problems where APAC devs missed a bug related to "has" check optimization because the sim ran the WW version.

I'm almost sure that there is no any reason to limit something according to ver in compiler.json. 

And example shows that unnecessary limitation of the ver can't allow too build the new version

- bug on the newset SDK

- impossible to use the older SDK

> And I'm happy with this bug because it's possible to make IQ file without checking this:-)

Yeah to be clear I’m not trying to make the lives of any devs harder. I’ve used older SDKs in the past as well.

I just want Garmin to clarify this situation once and for all by:

- announcing / documenting how the compiler’s device version checks are supposed to work and/or explaining what compiler you should use to build for a device with a given Connect IQ version

- fixing the compiler device version checks so that there’s no confusion about how they’re supposed to work. Unfortunately it doesn’t to be possible or practical to fix existing / old compilers, and whole point of the version checks is to prevent the use of *old* compilers