Eclipse is deprecated?

dpawlyk said:

Though, there are some adjustments to doing MC work in VS Code. 

For sure. I think there are usability improvements which could be made, like moving project properties to a full property sheet / view, as opposed to asking devs to set each individual project property via a separate command palette action. (I've already suggested this to Garmin in this forum.) The command palette is nice but it doesn't have to be used for *everything*.

And yes, there are bugs with the Garmin VS Code plugin (some of which also affect the Eclipse plugin now). That doesn't really reflect on VS Code's merits or failures as an editor IMO, unless you only plan on ever doing Monkey C work. Even for hobbyist devs, I feel that's a really limited outlook. Lots of hobbyist devs use git and github, and VS Code has much better git integration (through extensions) than Eclipse does, for example. It also has better support for Markdown. I also think learning either Python or JavaScript can be useful for any hobbyist (even just for personal use), and VS Code is also more useful than Eclipse in those cases.

flowstate said:

Shent-Aurkhan (SHN) said:

now I have it but it only launch the first project on the list when I launch the sim

even if the right file is opned in the OPEN EDITORS...

I've found that:
- Run (CTRL-F5) runs the last thing you built. Only if you just opened VS Code (so there's no previous build) will it prompt you to build the current project.

Hmm, I think I was half-wrong about this and Shent-Aurkhan (SHN) was right. Unless you explicitly build the current project before running, CTRL-F5 tends to run the first project in the workspace, not the last project that was built. I'm not sure what has to happen for the last built project to be "forgotten" though. My bad!

The test I'm doing is complicated by the fact that my workspace is just 4 versions of the same project, with most of the files as shared source. I haven't tested this with a workspace that contains completely unrelated projects yet.

This definitely feels like a bug at worst and bad UX at best.

flowstate said:

most of the files as shared source

how do you link files in vs code? Eclipse link source feature was something I really liked.

When moving from Eclipse, what I did was use jungles to access files outside The project.  Here's my basic jungle to use .mc file directly in barrell projects for example:

project.manifest = manifest.xml

srcBase=source
resBase=resources

#barrels background
barBgWu=..\BgWu
barBgOWM=..\BgOWM
barBgSettings=..\BgSettings

#barels misc
barSenHist=..\SenHisMisc

#barrels clocks.
barClkGoals=..\ClockGoals
barClkFields=..\ClockFields
barClkIcons=..\ClockIcons
barClkMisc=..\ClockMisc
barClkSettings=..\ClockSettings
barClkSun=..\ClockSun

###############################
#watchfaces, etc
###############################
#using fields and sun
#base.sourcePath=$(srcBase);$(barClkFields);$(barClkIcons);$(barClkMisc);$(barClkSettings);$(barClkSun)

#using goals
#base.sourcePath=$(srcBase);$(barClkGoals);$(barClkIcons);$(barClkMisc);$(barClkSettings)

#using goals and sun
base.sourcePath=$(srcBase);$(barClkGoals);$(barClkIcons);$(barClkMisc);$(barClkSettings);$(barClkSun)

#using settings
#base.sourcePath=$(srcBase);$(barClkSettings)

###############################
#Weather underground
###############################
#base.sourcePath=$(srcBase);$(barBgWu);$(barBgSettings)

peterdedecker said:

how do you link files in vs code? Eclipse link source feature was something I really liked.

TL;DR point to your shared source/resources in your jungle file to get the build to recognize them. Symlink your shared files under your project to get VS Code to recognize them (so that the "dirty" state of each project is properly maintained.)

1) i have a core/ directory that's shared between all the dupe projects. It contains shared source, resources, and a shared core.jungle file (which contains any shared jungle directives)

2) I symlink the core/ folder under each dupe project, but I don't actually actively use those symlinks to open files or anything. It's just there so that VS Code knows when a project's shared files are dirty. (Even if I symlinked core.jungle directly to each project's root folder, it would *not* automatically be picked up by the build, unlike the situation with Eclipse where Eclipse links would be picked up by the build).

3a) I edit each dupe project's local Monkey C settings so that core/core.jungle is part of the build

3b) Finally, in core.jungle, I add core/source and core/resources to their respective build paths. Note that I use the original path of the shared files, and not the symlinked path. e.g.

- Of course, each project still has its own monkey.jungle file which consists of a single directive to open manifest.xml

3a and 3b are what allow the shared files to be included in the build.

The advantage of referencing all the shared files in their original locations (as opposed to the symlinked locations) is that things like git integration work correctly.

You can do all of this without symlinks, but then VS Code won't know that your project has changed when you change shared files, which means it won't try to rebuild your project when you press CTRL-F5 (although CTRL-F5 seems to have a few issues wrt to the Monkey C plugin tho).

It's possible that another way to do this would've been to just symlink a shared monkey.jungle file to each project root folder; that way you could probably avoid changing the Monkey C jungle settings for each project. In hindsight, since each of my monkey.jungle files is literally one line which points to manifest.xml, it wouldn't have been a problem to incorporate them into the shared jungle file. When I first did this in Eclipse, for some reason I thought I wanted the freedom to have separate per-project monkey.jungle files and a separate shared jungle file, but looking back, that's probably overkill.

EDIT: I also change the VS code workspace settings to avoid following symlinks when searching (so you don't find duplicate matches whenever you search shared files):

    "settings": {
        "search.followSymlinks": false
    }

In my case I only have one workspace for the single project group (which is actually multiple projects with a single set of shared source), so I apply this at the workspace level. You may wish to apply this setting per-project if you have a workspace which contains multiple distinct projects, although I'm not sure how well that would work tbh.

EDIT: If you're on Windows, make sure to install Git with symlink support. I use this tool to create symlinks in the GUI (Explorer):

schinagl.priv.at/.../linkshellextension.html

Fwiw currently I use the solution to just link in my files/folders through the monkey.jungle, but the disadvantage here is that I can't open the files from within my vs code explorer where I could just double click in Eclipse.

Symlinks could work but are junctions and hard links correctly recreated/overwritten on target systems if tracked through a source repo like git? 

On some of my systems I will not be able to do all these steps ( gist.github.com/.../1efb64e57c37cfab7054c65702588fce ) as they are security impacting 

I think we'll both agree that the Eclipse link source feature works much better (and out of the box), The advantage is that it's part of your .project file and works with any source repository out of the box and restores properly on target systems.

It could make for an interesting vs code extension to recreate the eclipse link source feature within vs code somehow. 

With the way I do it, my common code is in barrel projects (I can either use the mc file, or use that code as a barrel, so I just add the barrel projects to the VS code workspace.

I don't use barrels as they don't support connect iq targets before connect iq 2.4 (I still think this is the wrong choice by the developer team to not add backwards support for something that's a compiler like feature - internally in the prg the barrel is basically a module).

In principle I guess I could use add folder but my current project structure is a lot more complex as I'm collecting files in several folders and in those folders I also have files that I don't want to be part of the project I'm linking them into. Potentially I could restructure some of it but that would be a huge task (and not sure I'll get to the flexibility I want).   

peterdedecker said:

Fwiw currently I use the solution to just link in my files/folders through the monkey.jungle, but the disadvantage here is that I can't open the files from within my vs code explorer where I could just double click in Eclipse.

Even if you use symlinks, as I said, I wouldn't recommend actually opening any of the symlinked files (or files under symlinked folders), because things like git integration won't work properly. e.g. if you open symilnked_folder/file.mc instead of original_location/file.mc, then you won't see which lines have changed since the last check-in. And if you have multiple symlinks to the same content, it's actually better if they aren't followed when searching in files, as otherwise you'd get multiple results.

Then again, I don't know what your project/workspace structure is like.

In my workspace for app X, I have project folders X1, X2, X3, and X4 (four clones of the same app), and shared source folder X_core, roughly speaking. I add each of those 5 folders as "projects" even though the core folder doesn't actually contain a buildable project. I have symlinks to the core folder in each of the real project folders, just so VS Code knows when a project is dirty, but I never open those symlinks when I work on the project, I always open the files from their original locations, so that things like git integration work properly.

peterdedecker said:

Symlinks could work but are junctions and hard links correctly recreated/overwritten on target systems if tracked through a source repo like git? 

No, junctions and hardlinks can't be tracked via git. They'll just appear as duplicate copies of whatever you linked. Plus, by definition, it's isn't possible to distinguish between two instances of a hard link, including the original file itself.

peterdedecker said:

I think we'll both agree that the Eclipse link source feature works much better (and out of the box), The advantage is that it's part of your .project file and works with any source repository out of the box and restores properly on target systems.

Yes, I agree, but then you're stuck with using Eclipse which has several other disadvantages IMO. Even when I used Eclipse daily for work, I would often open a faster, more lightweight text editor for certain tasks.

Plus, the reality is that Garmin is basically abandoning Eclipse going forward.

peterdedecker said:

It could make for an interesting vs code extension to recreate the eclipse link source feature within vs code somehow. 

I think there's an extension for that, but it only works with C# projects (which have support for "project references"). I saw another one which actually creates the symlink for you. I don't know enough about the architecture of VS Code to guess whether something like this possible. Like would it be possible for an extension to programmatically add more folders to the set of folders to be searched when you press CTRL-SHIFT-F? How would this interact with search excludes?

I also feel like it won't be added natively, but that's just my gut feeling.

Another solution for you could be to use git modules. Bu then the file system (and VS Code) will actually see multiple copies of all your files. But at least there would only be one copy in source control. If you're using this as a "utility library" scenario (as opposed to an "app clone" scenario), you would also have the advantage of being able to pin your library source files to a given git version.

flowstate said:

Then again, I don't know what your project/workspace structure is like.

I dislike copy/paste and I go big lengths to avoid having to copy any function. I have some files that are used in every project, others that are used in just similar projects and the files could be inserted at any level of my inheritance tree. I won't bother you with the details :)

Symlinks I won't use as they don't propogate well through git. 

I'll just keep blind linking through the jungle, which works. It just doesn't work so well as the Eclipse link source feature.