I'm struggling with barrels (debugger can't find sources, breakpoints don't work, etc) and thought using shared files with #include might be easier to deal with. How is the syntax for #include in Monkey C?
Monkey C is not K&R or ANSI C and does not have a cpp or C pre-processor. If you did everything from the command line, you could theoretically use #include if you manually run a C pre-processor, this this not not something that Monkey C itself supports.
Barrels can't be debugged, includes don't work. So I'm left with a platform that is pretty much unusable for development. I'll copy those shared files to each project now, just so that I get the apps finished before this frustration starts to affect my health. Man, is this a disappointment.
You can always use Sys.println() to see what's happening in barrels.
For me, the way I built all my barrels, is the .mc can also just be directly linked in the source for a project, so it's exactly the same code that would be in a barrel. They only time I've done something a bit different, is I have one that includes a custom font, and using it is a bit different than if it is in the project resources, and I handle that with a parameter when I call initialize in the barrell's .mc
So to switch between linked .mc files and barrels, I just delete the links and configure the barrels.
Quote: "For me, the way I built all my barrels, is the .mc can also just be directly linked in the source for a project, so it's exactly the same code that would be in a barrel."
That's what I ended up with and it does the trick for now. Thanks everyone for your suggestions!
Monkey C is not K&R or ANSI C and does not have a cpp or C pre-processor. If you did everything from the command line, you could theoretically use #include if you manually run a C pre-processor, this this not not something that Monkey C itself supports.
I've been using a custom pre-processor for my MonkeyC code for a while now. It's worked out great for injecting in test fixtures, changing behavior re: widget vs application, and adding profiling code. Because the code is commented out when not in use, you can be sure it's not landing in your binary, bloating your app.
I should probably look at the official Garmin way of doing this with barrels and exclude annotations and such, but the preprocessor approach is so darn simple, and just works.
