When does a barrel have multiple jungle files?

In the jungle reference I noticed this section:

Our second developer realizes that he wants to support rectangle devices as
well. These have been defined in a rectangleIcons.jungle. He includes 
multiple build instructions from MyIconBarrel by grouping the Jungle files
in square brackets [] like this:

# Include a specific Barrel from the 'barrels' directory and multiple Jungles from a Barrel project
base.barrelPath = barrels/MathLibrary.barrel;[MyIconBarrel/roundIcons.jungle;MyIconBarrel/rectangleIcons.jungle]

What does the MyIconBarrel project look like in this case? Also, what exactly do the square brackets mean? Even without them, you can present a list of barrel projects to pull in, simply separated by semi-colons, so I'm assuming this syntax is only needed for a single barrel project that has multiple jungle files. But how would I set up such a project?

0 jim_m_58 over 3 years ago

What are you trying to do? For me I don't need a jungle file in any of my barrels.

0 markw65 over 3 years ago in reply to jim_m_58

I'm trying to understand what that example is about. Why would you have multiple jungle files in a barrel, and how exactly would you set up the project so that that example worked.

This is what I *think* its about:

When you setup a barrel project, you can use annotations so that the consumer of the project can selectively pull in the bits of the code that they want. But you can't do that for resources. So instead, you have multiple jungle files, each of which selects just a subset of the resources.

But then, what happens when you *build* the barrel project? Do you just build it multiple times, once for each possible combination of jungle files?

0 markw65 over 3 years ago in reply to jim_m_58

jim_m_58 said:
For me I don't need a jungle file in any of my barrels

So what *do* you do?

I see that the command line monkeyc command has a -m option to specify the manifest file directly, but that its deprecated (you're supposed to use a jungle file to specify the manifest). But according to the help text, barrelbuild doesn't support that option. So you *have* to have a jungle file to build a .barrel. And if (as you've said previously) you don't actually build .barrels, but use barrel projects instead, again the docs imply that you have to point the barrelPath at the barrel project's jungle file.

Do you just mean you have the default "project.manifest = manifest.xml" jungle file?

0 jim_m_58 over 3 years ago in reply to markw65

"building" a .barrel is really just zipping up the barrel project. Each time you build your app for a different target, the barrel gets unzipped and compiled.

0 markw65 over 3 years ago in reply to jim_m_58

Yes, I know. But that doesn't answer the question of how it works without a jungle file...

0 jim_m_58 over 3 years ago in reply to markw65

markw65 said:
So what *do* you do?

My barrels are all generic code. I've got about 15 different ones right now. Sometimes, I pass things into the barrel from the main app - a specific font for example, so the main app worries about it and not the barrel.

You do want to start simple. There's a negitive to barrels in that they take more memory than just including the code from the barrel (about 1k)

I write my barrels so I can use the .barrel, or just include the mc file using jungles, so I can use the exact same code on the devices without barrel support or save the 1k where needed.

0 markw65 over 3 years ago in reply to jim_m_58

Ok, makes sense. But its still not clear how you build a .barrel file without a .jungle file?

When you say "just include the .mc file using jungles", do you mean modify the .jungle file of the importing project to refer to the barrel project's .mc files directly? In that case you're not really using the barrel mechanism at all (you wouldn't even need to refer to the barrel in the manfest file). Or do you mean you use the .barrelPath in the importing project? But in that case what do you point the barrelPath at, if there's no .jungle file in the barrel project?

Also, are you saying the 1k overhead is from using .barrel files, but not from using barrel projects (ie a non-built barrel)? Or that its from both, and the only way to avoid the overhead is to directly include the .mc files?

0 jim_m_58 over 3 years ago in reply to markw65

Yes, just including the mc from a barrel in the main app. Like I said, some devices don't support barrels, and in some, I want to save that extra 1k.

What it does is to share common code between apps, if they use barrels or don't. Only one copy of the source in only one place.

Within a barrel project, I don't have any targets set in the barrels manifest.xml, which means it can be used with any target. Another trick.

0 markw65 over 3 years ago in reply to jim_m_58

Thanks for all the info.

Sorry to keep on about the "no jungle files in barrels" comment, but I'm trying to understand the various ways that barrels are used.

So I understand the case where you just pull .mc files into your main project via the main project's jungle file, using <whatever>.sourcePath. For that, clearly the "barrel" project doesn't need a .jungle file... but it's also not really being used as a barrel, just a collection of source files.

But you're also implying that you *do* sometimes use real, built barrels (or at least barrel projects). ie declare it in the barrels section of the manifest, and pull it in via <whatever>.barrelPath in your main project. If thats the case, I'm assuming you *do* have a .jungle file in the barrel project. Can you confirm? And if not, how do you build the barrel? Or if you don't actually build it, how do you *refer* to it from your main project?

0 jim_m_58 over 3 years ago in reply to markw65

Ok, here's a barrels.jungle for a watch face that uses multiple barrels:

# Do not hand edit this file. To make changes right click
# on the project and select "Configure Monkey Barrels".

ClockIcons = C:\Users\James\workspace-prod\ClockIcons\bin\ClockIcons-1.0.0.barrel
base.barrelPath = $(base.barrelPath);$(ClockIcons)

ClockSun = C:\Users\James\workspace-prod\ClockSun\bin\ClockSun-1.0.0.barrel
base.barrelPath = $(base.barrelPath);$(ClockSun)

ClockSettings = C:\Users\James\workspace-prod\ClockSettings\bin\ClockSettings-1.0.0.barrel
base.barrelPath = $(base.barrelPath);$(ClockSettings)

ClockGoals = C:\Users\James\workspace-prod\ClockGoals\bin\ClockGoals-1.0.0.barrel
base.barrelPath = $(base.barrelPath);$(ClockGoals)

ClockMisc = C:\Users\James\workspace-prod\ClockMisc\bin\ClockMisc-1.0.0.barrel
base.barrelPath = $(base.barrelPath);$(ClockMisc)

ClockFields = C:\Users\James\workspace-prod\ClockFields\bin\ClockFields-1.0.0.barrel
base.barrelPath = $(base.barrelPath);$(ClockFields)

There's also things in the watch face's manifest.xml.

        <iq:barrels>
            <iq:depends name="ClockFields" version="1.0.0"/>
            <iq:depends name="ClockGoals" version="1.0.0"/>
            <iq:depends name="ClockIcons" version="1.0.0"/>
            <iq:depends name="ClockMisc" version="1.0.0"/>
            <iq:depends name="ClockSettings" version="1.0.0"/>
            <iq:depends name="ClockSun" version="1.0.0"/>
        </iq:barrels>

This is all done with Monkey C: Configure Monkey Barrels is VS Code.

Here's the monkey.jungle of another watch face where I use the same mc files, but don't use the .barrels.

project.manifest = manifest.xml

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

###############################
#watchfaces, etc
###############################
#using goals and sun
base.sourcePath=source;source-basic;$(barClkGoals);$(barClkIconsNew);$(barClkMisc);$(barClkSettings);$(barClkSun)
semioctagon.sourcePath=source;source-so;$(barClkSettings)

You make want to create a couple of simple barrel project and then experiment with them in a simple app.