I have a VS Code Project with multiple sub projects as they all share common base class code and some resources. When I export the sub project they are always named with the name of the parent project. Is it possible to control this somehow so that the output file so it takes its name from the sub project name? Otherwise when I export all the projects they overwrite each other.
I'm not sure CIQ supports sub projects. Can you run each of the subprojects in the sim and you can tell if you are running different ones?
For shared code, I use different projects along with barrels or common files (Which I typically have in the barrel project)
https://developer.garmin.com/connect-iq/core-topics/shareable-libraries/#shareablelibraries
I use symlinks to share common code between projects, but it has a few issues:
- You have to change VS Code's search settings to follow symlinks
- Certain features like git integration don't work properly with linked files/folders (at least under Windows)
Is there a command line command which lets you specify the output filename?
{SDK_PATH}\bin\monkeyc -e -j monkey.jungle -k {DEV_PRIVATE_KEY} -o {OUTPUT_FILE}
(Use {SDK_PATH}\bin\monkeyc -h to see all available options)
And: [https://developer.garmin.com/connect-iq/reference-guides/monkey-c-command-line-setup/]
Moving on from this I have found my configuration in Eclipse is providing multiple jungle files to the build process. I would like to continue this strategy with VS Code. I can get this to work from the command line but do you know what the process is to drive this from within VS Code so it will pick up this dependency when running from within the IDE? I have a base class module with its own jungle file and a number of child projects with their own specific jungle file
If I'm not mistaken, VS Code and Eclipse just automatically pass all files named "*.jungle" in the project root to the compiler command line. I'm curious how you're getting this to work in Eclipse.
And I'm curious how you're doing "subprojects" in VS Code. VS Code doesn't support subprojects as far as I know, it supports a multi-root workspace with more than one project, but each project should work the same way as it would in a single-project workspace. e.g., exporting a project should work properly.
Anyway, since you've obviously got everything else working the way you want in VS Code, I suggest
1) CTRL/CMD-SHIFT-P > Preferences - Open Workspace Settings
2) If you are actually using a multi-root workspace with multiple project, click Folder in the list of tabs (User | Workspace | Folder) and select your project, otherwise select Workspace.
3) Search for "Monkey C"
4) Edit "Monkey C: Jungle Files" and add your additional shared jungle file(s)
--
I'll explain what I usually do:
In Eclipse I used project links (which obviously only work in Eclipse) and in VS Code I use Windows symlinks (symbolic links). A symlink in Windows or Linux is basically a kind of pointer in the file system from one file/folder to another. It's like a Windows Explorer shortcut, but it's a first-class member of the file system (it requires file system support, whereas a Window Explorer shortcut is just a special kind of file). Contrast this with a hard link, which is also a kind of pointer to a file, but it's indistinguishable from the file itself (this has advantages and disadvantages).
The nice thing about project links in Eclipse is that they worked more or less transparently (although ofc you have to do everything from within Eclipse.) Everything else about Eclipse is terrible tho.
Symlink support in Windows isn't great (you have to change a system setting to be able to create them without administrator privileges), but it works. And they're source-controllable by git.
So let's say I have two projects which share a jungle file, resources and source files:
shared/
|
|-- source/
|-- resources/
|-- shared.jungle
|
|
project1/
|
| -- source/
| -- resources/
| -- monkey.jungle
|
project2/
|
| -- source/
| -- resources/
| -- monkey.jungle
What I do is use symlinks so that the shared files and folders appear to exist under each of the two projects. e.g.
project1/
|
| -- source/
| -- resources/
| -- monkey.jungle
| -->>> shared.jungle
| -- shared/
|
|-->>> source/
|-->>> resources/
|
project2/
|
| -- source/
| -- resources/
| -- monkey.jungle
| -->>> shared.jungle
| -- shared/
|
|-->>> source/
|-->>> resources/
Since I added a link to shared.jungle to the root of each project, the compiler automatically picks it up (or rather, the VS Code / Eclipse plugin automatically adds it to the compiler command line.)
Then I change my shared.jungle so the compiler picks up the shared source folders and resource folders, as well as the project-specific folders.
You will notice that it isn't really necessary to use symlinks for the shared resource and source folders, since I can just use the jungle file to specify whatever source and resource folders I want. It does allow me to open either project1/ or project2/ independently and still see all the files that I care about.
Only problems are:
1) I need to change the developer mode setting in Windows to allow creating symlinks without admin perms
2) I need to change the VS Code setting to follow symlinks when searching files
3) VS Code git source control integration doesn't work properly with linked files/folders. In this case I end up using the command line or other tools
If you always open all your projects in a one huge workspace, and your shared folders are always available, then this kind of thing probably isn't useful for you.
--
Some Windows symlink references:
https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/
If you use git, then another possibility would be to use git subprojects. Is that what you meant?
(This would also have the advantage of allowing different projects to use different versions of the shared "module(s)", if necessary)
Thanks I hadn't spotted that setting. All seems to be working now, well compiling with no errors, I need to go through and validate the functionality now. In order to get the shared code into the sub projects I add the following to the sub project manifest
