Comms in monkey.barrels?

Actually, it's not just one file. It's using barrel's code, so with 5 barrels, 5 linked files from different places. Using a directory means you want all the files. My way, I can pick which of the 5 I use for a given project (and I do - not all the projects use all the files. and some use different ones)

jim_m_58 good point. I guess it all depends on whether you are creating a generic shared library to be shared by dissimilar projects, or creating clone or sibling projects which share one set of project-specific code.

So I had it backwards -- your solution is more generic after all. Anyway, sorry for the not-so-great advice.

(Yes, I can see how this is much more of a kludge than barrels and other environments, static/dynamic linking and includes...)

If you're cloning a single app, yes, a directory makes sense. But in my case I have about a dozen barrels that I can use for shared code. One of two silighty different sets of 4 I use in my watchfaces, then I have one for a background process where I use that, one for sunrise/sunset if I use that, and the sunrise/sunset one I also use in other apps, and there's one for a common SensorHistory function that's shared with watch faces, apps, and widgets based on what I want to do. I just link in the functions I want for a specific project. And using the barrel approach for them, I can just use the barrels instead of an eclipse link.

It's very flexible if multiple differing apps are involved.

RaceQs did you add the shared source location to your jungle file? e.g.

Now you've got me really confused by your reference to the "shared source location"!

I have used Eclipse to create a link to the shared code file (sharedCode.mc) in my project's source folder.

Eclipse now shows sharedCode.mc in the project's source folder, (just as if it were a real file), See uploaded screenshot.


What entry would be required in my jungles file?

This Forums app implementation really sucks - it's taken me 1/2 hr to get this screenshot included!
https://drive.google.com/open?id=10FrwN_uVW8Egte2x5jCzxd_1JK5kULe3

RaceQs sorry, I was unsure whether you used my original suggestion of sharing a whole folder or Jim's suggestion of sharing one file. Since you have done the latter, you can ignore what I said about jungles.

I have noticed that Eclipse links don't work in all situations, but for me on Windows 10 at least, they do work with individual source files and the Monkey C compiler.

Since I unfortunately don't have Mac OS X to test on, I'll suggest using native symbolic links.

Open a Terminal , navigate to your project folder and type the following commands:
cd source
ln -sf ../../sharedfolder/source/sharedCode.mc sharedCode.mc


sharedfolder is the name of your shared folder.
I'm assuming:
- the shared folder and your project folder are in the same parent folder
- the shared file is under the source/ folder in your shared folder.

If not, adjust ../../sharedfolder/source/sharedCode.mc as necessary. ".." means "go up one folder level".

I don't see any reason this shouldn't work.

Yes, I did some testing yesterday which indicated that Eclipse Links really don't work on my Mac platform, but Unix Links work fine, as the Mac is BSD "under the hood".
That will be my solution.
Thanks everyone for your contributions.
One of the few benefits of developing for the Apple platform was that they also provide the IDE (Xcode), so when something breaks there is (in theory) a single supplier, but that has to be weighed against the many other prices one pays for locking in with the behemoth!
Eclipse is pretty good, but not perfect!

PS. have got to the bottom of the memory leak when using barrels that I referred to in post #9.

A memory leak occurs when you pass a global variable to a function. I stumbled on it when I implemented barrels, following the doco guidelines using modules, and had to pass some arguments to the shared function which had been global to my original project, but which were obviously not known to the barrels code.

I have replicated the issue in a simple test case.