[Olsr-dev] building 'framework' for Android

[Hans-Christoph Steiner]

This made me think of an approach that worked well for me on one project that was abstracted the USB HID API across GNU/Linux, Mac OS X, and Windows.  Basically, I set up an API in the main program, then implemented it in a separate file for each OS. 

For example, take a function like os_net_set_nonblocking().  That would be used wherever its needed, but would be implemented in os_net_linux.c, os_net_bsd.c, etc.  That API is then in a header that's used internally in the project.  Then during the build, only the needed OS-specific file is built and linked in. The current layout of olsrd.org/framework is pretty close to that.  This approach then removes the need for OS-specific #ifdefs and things like that and makes the code very readable.

The source to that project of mine is here:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/io/hidio/

.hc

On Apr 6, 2012, at 2:42 PM, Henning Rogge wrote:

> Some more explanations what my current idea is to clean it up:
> 
> I am thinking about making ALL os_xxxx functions inline defined in the
> os-dependent include files. Some of them might stay inline, the rest
> will call a os_linux_xxxx() or os_bsd_xxxx() function.
> 
> This allows the OS-implementation to inline anything not necessary for
> its code and keep the rest as normal functions without that much
> preprocessor magic (at the moment its too much of the magic ^^).
> 
> What do you think?
> 
> Henning Rogge
> 
> On Fri, Apr 6, 2012 at 19:52, Henning Rogge <(spam-protected)> wrote:
>> On Fri, Apr 6, 2012 at 17:57, Hans-Christoph Steiner
>> <(spam-protected)> wrote:
>>> 
>>> I was just looking through the common/, config/, framework, and packetbb/ repos to review it for building on Android.  My guess is that the best solution will be for me to write an ndk-build/Android.mk build system for it, since that is the standard native build technique for Android, and it integrates into the Eclipse Android ADT development environment that Google supports and most Android devs use.
>> 
>> You can build a Android compiler environment with the NDK and then set
>> the compiler (and the include directory I think) in a cross
>> compilation template for cmake (see /cross directory for an example).
>> After this you just create your own build directory, run cmake inside
>> it and you have your way to build the template.
>> 
>>> It looks like Henning recently moved over to using the compiler-defined macros _WIN32, __GLIBC, and __linux__, which makes life easier for things like this kind of stuff.  My question now is: is there anything there that assumes that __linux__ means __GLIBC__ or vice versa?  That is true on GNU/Linux, but not on Android, and sometimes those things are time consuming to track down, so I thought I'd ask to see if it rings any bells.
>> I must admit I am not sure... at the moment I have been working on the
>> linux environment, so if something has to be slightly tweaked for
>> android I am happy to hear suggestions.
>> 
>> I will most likely try to clean up the interface of the os_xxxx.h
>> header files to the os-dependent one (this was the first attempt, its
>> still too complicated), but I would be happy to discuss a good way to
>> do it.
>> 
>> Henning
>> 
>> --
>> Steven Hawkings about cosmic inflation: "An increase of billions of
>> billions of percent in a tiny fraction of a second. Of course, that
>> was before the present government."
> 
> 
> 
> -- 
> Steven Hawkings about cosmic inflation: "An increase of billions of
> billions of percent in a tiny fraction of a second. Of course, that
> was before the present government."