Compiler error

Hi,

Since installing the latest SDK I get the following error on compile "BUILD: ERROR: Unable to parse command line arguments: Unrecognized option: -c"

I'm  not sure how to resolve, -c isn't mentioned as a switch in the latest documentation but it works on previous SDKs (not sure when it was removed...)

Many Thanks,

Ralph.

  • Are you using Eclipse? Eclipse isn't supported anymore.

    If you are using VS Code, make sure the Monkey C extension is up to date.

  • Yes I'm using Eclipse, so there's no way to remove the -c switch?

  • Eclipse hasn't been supported or maintained for years.  You need to switch to VSC.

  • Yeah I recommend switching to VS Code. You'll have to install the Monkey C extension, as outlined here:

    https://developer.garmin.com/connect-iq/sdk/ 

    Garmin has added a lot of language teatures to the VS Code extension which are supposed to make it easier for you to code (that is, when they work).

    https://developer.garmin.com/connect-iq/reference-guides/visual-studio-code-extension/

    This Monkey C extension offers several features, including:

    • Real-Time Errors and Warnings – These will display when editing Monkey C, Jungle, Settings, MSS and Resource XML files. Any reported errors or warnings will display in the Problems tab.

    • Autocompletion – When editing Monkey C, Jungle and MSS files, autocompletion suggestions will be based on the detected scope. In the Monkey C editor, you can autocomplete functions with argument and type information by autocompleting the function keyword in a class or module.

    • References – You can find all references of any class or module member by right-clicking on it and selecting “Find all References” from the context menu. You can also search for a symbol in the document by summoning the command palette and typing @symbol name or search the entire workspace by summoning the command palette and typing #symbol name.

    • Hovering – See type information about a variable, function name, class or module by hovering the mouse over the symbol in question.

    • Go to Definition – You can jump to the definition of any class or module member by selecting “Go to Definition” from the context menu.

    • Folding Ranges – Comments, imports and regions of code can now be folded.

    Ofc it's not like those things were impossible in Eclipse, but Garmin never implemented them. And VS Code did introduce a new standard for doing things like this, which may have made it easier for them.

    If you want to stick with Eclipse, I guess you could try to decompile the sdk extension and edit the code, but I'm not even sure that would work and it would be an extreme step.

    You could also use the command line for building and running the apps, if you prefer to do your edits in Eclipse.

    I think Eclipse is terrible though. I've used both Eclipse and VS Code for work, and I can tell you that now I never open Eclipse for any reason except to open old CIQ projects which used a custom build system that's partially based on Eclipse. (I guess that's not possible now.)

    VS Code is not perfect. For one thing it's bloated, but then again so is Eclipse.

    VS Code has many more modern features than Eclipse. Things that have been standard in coding editors for 10+ years, like multiple cursors and a command palette, are either missing, poor implemented, or only recently added to Eclipse.

    Plus the popularity of VS Code (it's the number 1 editor for devs) means it has a ton of useful extensions.

    Finally, if you want to code in popular languages like TypeScript or Python, you will find that VS Code is well-suited for the job.

  • Many thanks for the comprehensive response, Is it easy to migrate the code from Eclipse to VSC? And is there a device simulator available for VSC? I find that invaluable for testing the app on different watches etc ..

  • Yeah the simulator comes with the SDK.

    Is it easy to migrate the code from Eclipse to VSC?

    If you've been using recent SDKs, then there should be no problems there. You might find there is a learning curve to Visual Code, but it will serve you well if you ever decide to try other modern editors like Sublime Text or IntelliJ IDEA.

    I will be honest and say that some people absolutely hate VS Code, but if you want to develop Connect IQ, you don't really have much of a choice, unless you use one editor just for editing, and the command line for building and running.

  • Here's a some examples of built-in features which make coding in VS Code a better experience than Eclipse:

    - bracket-pair colorization - this color-codes matching brackets so you can tell at a glance which ones go together. Tbf Eclipse does have an extension for this. Once you get used to this, you will hate any code editor which doesn't have it.

    - command palette - all of your editor commands are available from a drop down menu, with text search, using one simple keyboard shortcut (which is becomes common across other tools meant for devs): CTRL-SHIFT-P / CMD-SHIFT-P. Yes, Eclipse has something similar, but it doesn't work very well.

    I would argue this is the only command shortcut that you have to learn at first. Everything follows from there.

    - fuzzy search - certain searches will match on non-consecutive characters in the result. e.g. in the command palette, you could type "osm" and it would match "Monkey C: Open SDK Manager". Same goes with searching for files in your project (CTRL-P / CMD-P)

    - heavy focus on keyboard usability - It's well known that constantly switching between the keyboard and mouse is inefficient, so VS Code allows you to keep your hands on the keyboard as much as possible, while not necessarily having to memorize too many shortcuts [due to the command palette]

    - multiple cursors - You can easily select multiple instances of the same text and edit them simultaneously. This is such a huge boon to productivity (a lot more powerful than simple search/replace or even rectangular select - for example, you have complete control over *how many* instances you select, and it's done in a very intuitive and visual way - by adding cursors one by one). Modern editors have had this for 10+ years, but Eclipse only gained this feature a couple of years ago

    - sticky headers - When you scroll through a file with heavy nesting, the headers for the current section(s) stay pinned to the top of the editor so you don't lose track of where you are

    - modern console/terminal - supports clickable links, emoji, and multiple panes. In contrast, it took Eclipse 20 years to persist the word wrap setting in its console

    - case-preserving search and replace: https://devblogs.microsoft.com/visualstudio/keep-your-casing-with-case-preserving-find-and-replace. This is a feature that was requested by an Eclipse user in 2008, and one of the maintainers closed the bug report, telling them to use regular expressions. 

    Except their regular expression implementation doesn't really cover something like replacing "testword" with "newName", which should ideally work in several cases:

    - testword-> newname

    - testWord-> newName

    - TestWord -> NewName

    - TESTWORD -> NEWNAME

    Looking at old discussions, it's funny how many people question why anyone needs to do anything like this automatically. Well, it's obviously something that devs do all the time [since programming languages have various capitalization rules for different types of identifiers, like classes vs variables]. Instead of giving users [devs] what they want, one way of thinking is to tell them that it's not possible, practical, or necessary. Well, it obviously is practical and useful, otherwise it wouldn't have been implemented.

    - automatically preserving unsaved files on exit - along with the command palette, this is another big feature that most modern code editors have and most old-school editors do not [at least not in the current form]. With older editors, you always had to decide whether to discard or save changed files on exit.

    With newer editors like VS Code and Sublime Text [10+ years old at this point], if you exit the app in a certain way (like selecting File -> Exit instead of closing the individual windows) or just shut down your computer, the contents of all unsaved files are preserved on exit *without saving them to their original location" [they don't even ever have been saved once - they could be new files]. When you reopen the editor, the entire session is restored, including unsaved files and their unsaved state. This means that you don't have to decide to apply or discard all changes just because you exit the editor or reboot your PC, so you're at much less risk of losing data for either reason. If you had to apply all changes, you might lose the original contents of some files you wanted to keep, or if you had to discard all changes, you might lose some new changes you wanted to keep.

  • Again many thanks, it's been very enlightening, I'll install and see how I get on! I did manage to compile it in Eclipse using the terminal and removing the -c code but it's a frag honestly and not a long term solution...