On Wed, Nov 02, 2011 at 03:44:00PM +0000, Toby Gray wrote:
> The reason for this is, I suspect, due to the Android NDK tools being
> able to target several different Android versions. Each version has
> different functions present and so the usr/include for that particular
> version is included. So you end up with the following search path (with
> uninteresting includes removed):
> -I/home/tg/src/barry-trees/tobygray/barry/android/jni/barry
> -I/home/tg/Android/NDK/platforms/android-3/arch-arm/usr/include
Thanks Toby for your detailed explanation!
Is there a way to reverse the above includes? This should fix the problem
as well, since Barry should never be directly in the main include path.
For example, when installed on a system, Barry's copy of time.h is in
the following path:
/usr/include/barry18/barry/time.h
The -I option for Barry should never be -I/usr/include/barry18/barry but
only -I/usr/include/barry18
When building from source, there is a barry18 symlink which serves this
purpose too.
Any application that needs Barry headers would then include:
#include <barry/barry.h>
Just including <barry.h> won't work, or shouldn't work, if the include paths
are correct! :-) This also hides time.h, so that it can only be included
if specified directly as <barry/time.h> or if included as "time.h" from
a header already under barry/.
The above include then indirectly does:
#include "time.h"
which should look in the same directory that barry/barry.h is in.
This should all hold true when building the library from source as well,
although the include directory hierarchy is done with symlinks instead.
If you can somehow adjust Android's build system to make sure that all
system directories are listed first, and that all Barry headers must
be included via <barry/...>, then this shouldn't be a problem.
Is this possible?
> I've also done a tidy on my github branch to merge the changes which I
> then undid (such as the iconv.cc one and the build script as a shell
> script instead of a Makefile). I'm very impressed by how easy this was
> to do with "git rebase --interactive d7816d80".
Excellent! I use rebase a lot, too. :-) It's extremely handy.
> Finally I apologise for the whitespace changes you've had to make, I
> thought I'd managed to set up my emacs to use the correct indentation
> levels and characters for the Barry coding style, but I evidently didn't
> set it up correctly for all file types.
I'm a bit anal about whitespace. :-) Sometimes git is even more precise
than I am. :-) Don't worry too much about it, but I do appreciate the
extra care.
- Chris
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel
