Some things I noticed in comparing the .gitignore to the one I use in my addons:

• why exclude .xcworkspace?
• missing:
  • *.cbTemp (for Codeblocks)
  • *.a & *.dll
  • *.app (OSX) & *.exe (Win) .. I suppose these are covered by the bin folder rules?

When the project generator will be able to generate project files for addons, too (OF issue openframeworks/openFrameworks#1234), we can drop the project files from addons' examples. Then, the following gitignore entries will come in handy.

# Project files should not be committed to the repo. They will (soon) be 
# auto-generated by the project generator.

#XCode
/*/*.xcodeproj
/*/Project.xcconfig
/*/openFrameworks-Info.plist
/*/ofxiphone-Info.plist
/*/iPhone_Prefix.pch
/*/*/*/Default.png
/*/*/*/Icon.png

#Code::Blocks
/*/*.cbp
/*/*.workspace

#Visual Studio
/*/*.sln
/*/*.vcxproj
/*/*.vcxproj.user
/*/*.vcxproj.filters

#Eclipse
/*/.cproject
/*/.project
/*/.settings/

#Linux
/*/Makefile
/*/config.make

@obviousjim and I were talking about conditional includes for addon header / impl files and thought that it might be useful to suggest that all addons specify a #define that announces the addon's presence to the system. That way other addons can conditionally include bridge classes. A proposal would be something like ... in the main class ofxMyAddon.h a define like:

#define DEFINE_OFX_MYADDON

And then in the bridge classes of a dependent addon like ofxMyAddonThatDependsOnofxMyAddon.h one would do something like:

#ifdef DEFINE_OFX_MYADDON`

my special class that required OFX_MYADDON

#endif

Right now it is possible to specify required addon dependencies in addon_config.mk, but this is addressing the situation where an addon can optionally add features if an addon is present.

@arturoc @atduskgreg @bilderbuchi

The ADDON_CFLAGS is documented but ADDON_CPPFLAGS is not.

It would be helpful to have this documented as it makes clear that both variables are looked for, and what its exact name is (as opposed to, for instance ADDON_CXXFLAGS).

Hi all,

It seems that the core oF does not follow any particular convention about the ways that its pre-compiled libraries are named. Sometimes they are libMYLIB.{a,so} and sometimes they are just MYLIB.{a,so}. For the purposes of consistency (and a slightly more streamlined makefile system), I'd like to hear what folks think about renaming our core libs to be prefixed with libMYLIB.{a,so} and require addons to also use that template model. The idea is that we compile using the standard -lMYLIB with search paths -L that can be reordered by the user. While obviously specifying the full path of a lib without an -l flag is possible, I think it will help keep things cleaner and more consistent across platforms.

Of course, the downside is that some project templates will need to be updated but we can do it all at once in my Makefile branch and roll it out across the board.

@arturoc @bilderbuchi what do you think?

Hey, I'm using this template to build an addon with of 0.9.8. I'm having this QuickTime error that was present in 0.9.4 but was fixed in 0.9.8. Also, do i need to include the "lib" folder in my addon repository?

Collection of things unclear/to be discussed/decided/:

• bin folder in addon root: What is this for? Do we want/need it?
• role of install.xml: Do we still use it. What should be in there? How does an empty one look like? (these are probably questions for @arturoc, @ofTheo.

I think the addon template should also have dependency and compatibility info included in some file (xml?) or other automatedly processable form (special strings in the README?). This was discussed a couple of times already, but the discussion never came to a conclusion. Maybe now is a good time to do this.

What info should be included?
How should it be included?
How do we allow/account for future features like automated addon download by PG (openframeworks/openFrameworks#1233)?

@obviousjim @atduskgreg @ofTheo @ofZach @arturoc: Thoughts?

see openframeworks/projectGenerator#287

I'm raising two issues here, both quite distinct but related.

1. I know namespaces are a hot topic. Here's a problem I just ran into, try using ofxLeapMotion and ofxMultitouchPad in the same project. They both have a class called 'Finger' so won't compile. Calling the classes ofxLeapMotionFinger and ofxMultitouchPadFinger are really ugly solutions. This is what namespaces were invented for so I suggest we encourage addon developers to use namespaces. Luckily, Leapmotion has its own namespace, however there is a 'using namespace Leap' at the top of ofxLeapmotion header file which creates ambiguity. It is an easy hack fix, (remove the 'using', and explicitly state Leap::Finger instead of assuming it via the using). So I suggest:

   • addon developers always use namespaces if their class names are likely to be common names
   • addon developers never have 'using namespace ....' in their headers, but always explicitly state the classes (e.g. Leap::Finger)

2. There is another common and similar problem. Having header files with the same name. E.g. Finger.h, Control.h etc. When doing #include "Finger.h" you can run into ambiguity problems if different addons have a Finger.h. Using ofxLeapMotionFinger.h or ofxLeapMotionControl.h is again an ugly solution. I've started using relative paths to the addons folder, makes readability better I think. e.g.

   include "ofxMyAddon/src/Finger.h"

   For this to work '../../../addons' needs to be added to the header search path. If add-on writers have guidelines to follow this convention then adding '../../../addons' to the project once will ensure ALL addons will always work, and we won't need to add different header search paths for each addon (unless the addon is using a 3rd party lib, e.g. oscpack, which has it's own requirements). In fact perhaps this could become part of the example projects and template / PG?

the project generator uses this :

https://github.com/openframeworks/openFrameworks/blob/develop/addons/ofxOpenCv/libs/opencv/lib/win_cb/libsorder.make

to specify the correct order for libs, which is important on some platforms where linking order matters. it might be useful to have an example of that, or at least mention it in the readme.

also, it's useful to note that the use of this file was changed from how it worked in linux in earlier versions, where it was appending things to the names listed in this file. that's no longer the case since that didn't make sense on all platforms. Some addons which have this file for linux might need to make sure they're updated.

The suggested example naming uses a "-" which iOS doesn't support in the bundle name. iOS examples should be "exampleIOS", etc.