I think you are making this more complex than needed,  With jungles, you can just use different code (mc files) based on the device.  Here's a example for one of my apps that will draw a breadcrumb trail by default but use local maps on devices that have them,  My source is setup like this:

source has all the common stuff.  source-maps for devices with local maps, and source-nomaps, where I use breadcrumbs.

Then, in my monkey.jungle file, there's this:

# default is breadcrumb
base.sourcePath=$(srcBase);source-nomaps
base.resourcePath=$(resBase)

# use maps
fenix5x.sourcePath = $(srcBase);source-maps
fenix5x.resourcePath = $(resBase);resources-maps

I do something similar on apps that support the Instinct2/2s/crossover where using jungles, they use a different xyzView.mc and different properties/setting (setting colors on a B&W device doesn't make sense!)

I have

resources
resources-basic
resources-so

source
source=basic
source-so

and then in the jungle:

base.sourcePath=source;source-basic
semioctagon.sourcePath=source;source-so

base.resourcePath=resources;resources-basic
semioctagon.resourcePath=resources;resources-so

Either you haven't read my full question or i wasn't clear. All that i already do, that's how 1 app behaves differently on old and newer (and b&w devices or on epic that doesn't have fit files)

What I want to do now is this:

gorilla.jungle -> manifest-a.xml, basic features and feature Z - for all devices + feature H for new devices

chimpanzee.jungle -> another app: manifest-h.xml (different I'd) only for devices with 32k memory, basic features + feature Z

I know how to do the directories, exclude annotations, etc for both.

What i don't know is how to integrate it as flowlessly with VSC - i guess if it's possible then using different entries in launch.json

Ah, and i guess I'll also need a way for Export Project using gorilla.jungle vs chimpanzee.jungle

Again, jungles itself

Imagine

ProgA
ProgB
CommonABSource

You build ProgA and it uses that manifest, and same with ProgB, but they both can use the same source

flocsy🤠 said:

Either you haven't read my full question or i wasn't clear

My 0.0000002 cents is the letter of what you're asking for is impossible afaik.

The spirit of what you're asking for is certainly possible, but it will probably require some reorg. EDIT: Unless you skip step 1) below, in which case existing files and folders won't need to be moved, but you'll still need to create a new subfolder under the root folder to contain the 2nd project.

I'm gonna assume your project is called myAwesomeProject for the purposes of this suggestion.

1) Move the contents of myAwesomeProject/ to a new subfolder under itself named basic

EDIT: as noted below, you can skip this step if you want to preserve your existing folder structure

2) Create new folder under myAwesomeProject/ called advanced

3) Make symlinks from any relevant folders and files under myAwesomeProject/basic/ to advanced/. (e.g. source, resources, etc.)

4) Enable "Follow Symlinks" in VS Code if you want (this will allow search to follow symlinks)

Your folder structure looks like this now:

myAwesomeProject/
|
----basic/
|   |
|   ----source/
|   |
|   ----resources/
|   |
|   ----monkey.jungle
|   |
|   ----manifest.xml
|
----advanced/
|   |
|   ----source/ -> ../basic/source/
|   |
|   ----resources/ -> ../basic/resources/
|   |
|   ----monkey.jungle
|   |
|   ----manifest.xml

I know it's not what you want to hear and it's probably something you've already considered but I don't have a better solution.

With this solution you can also have additional jungle file(s) which are shared between the sub-projects, for stuff that's common, but you probably knew that already.

One downside is that symlinked files/folders don't have 100% great support in VS Code - things like git integration won't work properly. If your workspace always includes both projects perhaps this won't be a problem.

If you only care about building from the command line you can of course pass in the desired jungle file that way. Unfortunately I don't think launch.json exposes the options you're looking for. If you use CTRL-SPACE in the launch.json editor you can see what options are available in the run config (based on the JSON schema), and there's nothing for customizing the command line or selecting a jungle file.

Even if launch.json could do what you wanted, it wouldn't help you when it comes time to export anyway. You really need two separate projects, and I don't see a way to do that without having two project folders. I think this is actually a pretty sensible limitation all around - it reduces complexity. If you want additional complexity, there's always the command line, makefiles, etc.

If you have your heart set on preserving the existing folder structure (I totally get this btw), I found that you can actually have one project exist as a subfolder of another project in VS Code (for some reason I assumed this was impossible but I should've known better since it works fine for git subprojects.)

So you do everything I suggested, except moving existing items to the basic/ subfolder.

myAwesomeProject/
|
----source/
|
----resources/
|
----monkey.jungle
|
----manifest.xml
|
----advanced/
|   |
|   ----source/ -> ../source/
|   |
|   ----resources/ -> ../resources/
|   |
|   ----monkey.jungle
|   |
|   ----manifest.xml

You can even add a .gitignore to myAwesomeProject/ with the following contents

advanced/

Then open User Settings and enable Exclude Git Ignore

This will hide the advanced/ folder from your top-level myAwesomeProject explorer tree (so you don't have to see it twice.)

e.g.

BTW, hope this isn't a dumb question but do you really need two apps (as in two manifest.xmls, and presumbly two app ids / store entries)?

Can't you just add the new feature to the existing app, but only for newest devices? The only case where I have a separate version of my app for newer and older devices is where:

- it's very memory sensitive (especially on older devices)

- it has an open-ended config (the more complex the config, the more memory it consumes)

In that case I have a "legacy" version of my app which:

- only supports old devices

- only gets bug fixes, never feature updates

- is always built with the oldest SDK possible

I do it that way because supporting newer devices invariably requires SDK updates, and SDK updates sometimes result in increased memory usage, even on older devices which can't take advantage of any new SDK features.

The "modern" version of that app gets feature updates, and is supported by old and new devices. (But it still has some features which are exclusive only to the devices which have more memory.)

For all my other apps, I have one version of the app for all devices, and any features which differ between devices are documented.

EDIT: My other use case for sharing entire codebases between apps is when I have separate widget and device app versions of the same app.

The reason i'd like to have 2 apps for the mid-range devices is that the new feature i am working on is something that i assume many will want to use. The only way I could squeeze it into the existing app for mid-range (32K DF) devices if i remove another big feature(s) which other than pissing existing users would also mean that the common parts (App name and description in the store) would be missleading. I think this is a special case of the "memory sensitive" in your list.

I'll give it a try soon. I anyway already have lots of symlinks because I made all the strings in resources-eng link to the default so it has a better chance in Garmin Express (though it doesn't seem to work) and if I don't have all the strings in English then there are tons of warnings...

This is the only place I've ever used VSC, so not sure what doesn't work as supposed to be when using symlinks...