Actually excluding annotations

I added base.excludeAnnotations = keepout to my jungle file, but while it doesn't complain it doesn't work. So far the only thing that actually works to keep that section out is to comment it out. I can can tell when the memory is about 3k less that it's not compiled in. Documentation around this is just sad, so I hope someone has some tribal knowledge.

0 jim_m_58 over 2 years ago in reply to andyj713

A barrel is basicly just a zip of the barrel project, that gets unzipped and compiled each time the main app gets compiled. It also has overhead vs just using the mc file directly.

0 andyj713 over 2 years ago in reply to jim_m_58

That's what I see, but I still don't get how setting exclude in the barrel's jungle file would work for a non-watchface app.

0 jim_m_58 over 2 years ago in reply to andyj713

Try is and see what happens. Then you can look at doing things in a better way.

0 andyj713 over 2 years ago in reply to jim_m_58

What would a better way be?

0 andyj713 over 2 years ago in reply to jim_m_58

The monkey.jungle file in the barrel just has this "project.manifest = manifest.xml". There aren't any other jungle files in the barrel. I need another one?

0 jim_m_58 over 2 years ago in reply to andyj713

Include the same exclude you have in the monkey.jungle for your main app.

You main app also gas a barrels.jungle (or should) that you manage with Monkey C: Configure Monkey Barrels in VSC

0 andyj713 over 2 years ago in reply to jim_m_58

It does. That's where I put the exclusion line in, but it doesn't seem to be excluding.

0 jim_m_58 over 2 years ago in reply to andyj713

You put the exclude in your barrels.jungle? Did you try the monkey.jungle in your barrel project?

That said, there are two ways I handle similar things.

1) create a second barrel with just what you want excluded from the first and comment it out in the first. Then add the second barrel your apps that use that feature. I have one app that uses 6 barrels and others that don't use the same ones, depending on what the app requires.

2) skip using the .barrel and just pull in the code. I tend to do this as barrels add an additional memory overhead to your app (1k per barrel if I recall)

Here for example is what I have in the app's monkey.jungle project that uses the mc files from two barrel projects (BgWu and BgSettings) No overhead, yet shared code

srcBase=source

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

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

0 jim_m_58 over 2 years ago in reply to jim_m_58

as an example of #1 (which sounds similar to what you want to do.)

Say I have a barrel with stuff I use in many watch faces.

But I have a function to get sunrise/set that I use in some watch faces, but I also use sunrise/set in widgets and device apps.

I could include sunrise/set along with my common WF barrel. but then it will impact watchfaces that don't do sunrise/set. And if I want to use sunrise/set in a widget. it would pull in the common watch face code that the widget doesn't use.

The simplest solution is use two barrels. One for the common WF code, and a second barrel for sunrise/set. That way the watch faces with or without sunrise/set have no memory impact (other than the barrel overhead), and same with the widget that does sunrise/set. Only include the code that's needed.

And by bypassing barrels (#2), there is no barrel overhead and every app has what it needs and nothing more.

0 andyj713 over 2 years ago in reply to jim_m_58

Option 1 is what I guessed would be the most direct. Not quite as elegant but sounds easier to implement. Option 2 sounds like a variation of include files where you add whole files to a project without having to make a copy of the file (and then having to manage multiple copies). Following option 2, if you add the file to a project, does it need to be a barrel / module, or can it be just a class?