Agreed. It was sort of an inside joke. There used to be a ccache executable but that was deleted a long time ago. I am in no way advocating for ccache as the directory or library name.
> On Apr 1, 2020, at 2:48 PM, Robert Houghton <rhough...@pivotal.io> wrote: > > 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 >> >>
