Quick note: ccache is a C/C++ compiler cache. Examples using 'ccache' as the name are confusing.
On Tue, Mar 31, 2020 at 3:56 PM Jacob Barrett <jbarr...@pivotal.io> wrote: > > > > On Mar 31, 2020, at 3:06 PM, Blake Bender <bben...@pivotal.io> wrote: > > > > We in this instance means the native client team. As far as specific > > comments, I'm going to suggest we not go down that road, because this > feels > > a little more adversarial to me than it needs to be already. > > Sorry it feels adversarial. From below I think there is a misunderstanding > of my preferences. > > > Suffice to > > say that from my own perspective, in both what you wrote and what I got > > from our in-person conversation on Monday, your answer to the general > > question "Should the C bindings be part of the native client?" appeared > to > > be no, thus a separate repository seemed a perfectly reasonable > > assumption. I had hoped to do this in the geode-native repo to begin > with, > > so your assent to this makes life easier. > > This may be the point of confusion because I have never intended to give > the impression that the C-bindings should be separate from the geode-native > repo. My examples even integrate it with the geode-native project. I do > believe it should be separate sources and separate includes. I would not > want to be doing a C++ project and have C functions clouding my IDE or > vice versa. Perhaps that is where the confusion comes from. > > > As far as my concerns about inefficiency, what I meant is essentially yes > > we have multiple copies of the same code in the release, and this always > > makes me a little uneasy. I've seen a lot of compatibility bugs in my > > career having to do with different products having different versions of > > the same code, so my natural inclination is to avoid it when possible. > > Having both C++ and C-style functions exported from the same library > > doesn't give me any heartburn at all, so simply compiling the C bindings > > into the existing shared library just means one less copy of the code in > > the installation. I fear I am in the minority in this opinion, however, > > and it's not something I'm really doctrinaire about, so I'll defer. > I would really like to understand your concerns but I don’t understand how > combining the symbols into a single file resolves the versioning issue? Can > your help me understand what the different produces with different versions > means and how it would apply to this case? > > If the C and C++ symbols are both exported from the same shared library > would you have a common include directory as well or would you spit the > includes? I could live with a combine library but not a combined include > headers. > > > So are we good here? I'd like to get the RFC wrapped up and move on to > > building this. > > Do you feel there is a consensus? I feel like there is a lot left that > isn’t either in the original RFC, hasn’t been discussed here or is still a > sticking point. You could update the RFC with what we have discussed and > see if consensus is reached. > > Sticking points: > * Single or split shared libraries > * Single or split includes > * Single or split source repository > > Undefined: > * Exception handling (I gave one example but didn’t get feedback or > consensus) > * Namespacing/Prefixing > * Pattern and naming conventions for new, delete and class methods. > * Handling of (de)serialization hand off or callbacks into non-C code > > Agreed: > * Strong types with opaque struct pointers > * No complete structs in the API/ABI > > -Jake > >
