Re: [gpsd-dev] [PATCH] Various fixes to build for android

[Eric S. Raymond]

Samuel CUELLA <address@hidden>:
> fd_set was needed in gpsd.h for gpsd_await_data. Including <unistd.h>
> fixes the problem. In fact the bug is still present but shadowed by
> another part of the patch you've merged: In SConstruct, HAVE_GETSID not
> defined adds "#include <unistd.h>" along with getsid prototype in gpsd.h.
> 
> I'll add a fix for that in the next round.

I think you'll find I've already fixed this.
 
> > Alas, this patch is flat wrong; it violates the way the code is layered.
> > These functions are callouts from the library that are *intentionally* 
> > defined different ways by different binaries.  We need to find a way to
> > beat your linker into doing the right thing here.
> 
> It seems that I just didn't got the intent.You're using symbols in the
> library that the "client" executable *must* provide and you rely on the
> linker to do the library used -> executable defined linking.
> 
> Is that documented somewhere? Would you agree on using a different
> approach, like defining function pointers to be filled-in by the client
> code if needed (and maybe a default implementation)?
> 
> P.S: I've seen comments and a patch from Matt about that too. I'll try
> it on Android to see if that works (guess it will). Do you agree with
> that direction ?

The patch doesn't seem wrong to me, but I don't see any advantage from it 
either.  We can't make the dependency go away, the best we can do is get cute
about how it's expressed.  Where's the gain?  What problem is Matt's patch
solving?
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>