On Thu, Nov 28, 2013 at 11:46 AM, Steven Walters <kemu...@gmail.com> wrote:
> > It's important to be clear about the difference between core concepts in > the > > model (like the logical structure of a CppSourceSet, CSourceSet, > Component, > > etc) from what is simply a 'convention' that maps that logical structure > to > > the filesystem. > > > > Regarding the underlying model, I think we probably need quite a bit of > > flexibility: > > 1. Each LanguageSourceSet should be able to have a set of private header > > files, that only apply to that source set. > > 2. A component should have a separate shared HeaderDirectorySet that is > > shared between all LanguageSourceSets in a component. > > 3. A component should have an API HeaderDirectorySet that is available to > > any other component that depends on this component > > > > Regarding the layout conventions for this model, we have a number of > > options, and we don't have to choose just one. The basic convention in > > Gradle should be simple, consistent, work for many projects, and > > (importantly) easy to replace with your own. > > > > - For 1. we could assume that headers are mixed with the sources (empty > > HeaderDirectorySet) but make it easy to add additional directories. > > - For 2. we might use the current convention of 'headers' or perhaps > > 'include' is better. > > - For 3. I think defaulting to the shared headers might make sense? > > > > In my interpretation of the above header/include categories, I see > #1 could be nomenclated as "language private" > Remember that a component may contain multiple source sets of a particular language. Not sure how useful this is, but it's currently possible. However, I'll stick to 'language-private' for now. > #2 as "component private" > #3 as "component public" > > With this nomenclature, it raises an eyebrow to default the 'component > public' set to the 'component private' set. > > Trying to exemplify these to validate the scenarios (in attempts to > clarify the necessity/uses of them) > #1 makes seems to make sense as a language could have internal common > APIs for handling basic functionality that isn't needed outside of > that language, such as > * macros in ASM > * commonolizing string charset conversions in C/C++ > > > #2 is bit more of a peculiar scenario > > Most use cases that _I've_ particularly seen around possibly wanting > #2 is of the form > A) Language X declares functions or variables that language Y > implements. - 'Y' is implementing for 'B' > B) Language X declares functions or variables that language Y can > read/access. - 'Y' is using 'B' > > Exemplifying A, > C/C++ headers declare functions that (pure/non-inlined) ASM code > implements. > depending on the ASM compiler, it may or may not be able to directly > include the C/C++ headers. > - If the ASM compiler can, then those headers would be 'shared' > - If not, then the C/C++ headers could remain 'private'. > > Exemplifying B, > My interpretation of the example Michael started with, around the > "resource.h" would fall under this: > "resources" declares and implements variables that C/C++ can access > (to call appropriate Windows APIs upon them) > > In a very strict interpretation, C++ being able to use C headers and > call C functions/use C variables also falls here. > I'm not really familiar with Obj-C at all, but given the 'C' > derivative naming, seems like it should be able to access C > functionality like C++ can. > > > However, is there a need/benefit of modeling "component private" > specifically? > It seems that _within a component_, allowing native languages to > access other languages' "private" headers would be just as simple. > > Or, a possibility here is that "component private" is modeled but > simply defaults to the collection of private headers for each of the > native languages... > OK so the question is whether the 'component-private' / 'language-private distinction makes sense at all. Perhaps this would be over-complicating things for the sake of unneeded flexibility? If yes, then you're idea of conventionally defaulting the 'component-private' headers to the aggregate of the 'language-private' headers probably makes sense. If no, then we would simply have 'private-headers' and 'api-headers' for a component, with a single conventional directory for each. The actual names of these directories is bound to be subject to a nice 'colour of the bike shed' argument :). > #3 Is an agreed upon/standardized necessity, due to requiring the > ability to expose/publish (supported) APIs between components. > > As to how this should be defaulted... it'll probably likely depend on > the filesystem "layout" > - this'll be interesting to see manifest if gradle does decide to > offer some "layout" options. > a) if the layout is of the private and public subtree header form, > then default to the "public" header trees seems to make sense > b) otherwise, defaulting to the "component private" (if that remains > modeled, or the private ones if not) header trees would likely make > sense. > We're currently developing a new configuration model (model-rules) that should make it much easier to inspect the filesystem and attempt to detect the convention being used (eg use a 'public-headers' directory if present, otherwise use the standard 'headers' directory). Until then, we'll need to make it easy to apply a convention plugin that configures the directory locations. > > > Finally, we definitely want to have conventional extensions for each > > LanguageSourceSet. The fact that we don't have this currently is just an > > implementation oversight. We should be pretty inclusive in this regard, > but > > obviously have *.h in your source tree should "just work". > > > > The important part is that the model needs to support all reasonable > ways of > > working. The conventions should help to make the model clear where > possible, > > and should be easy to override. It may be that we have a set of 'layout' > > plugins that can apply different common conventions. > > > > Thanks for your input, guys! > > Daz > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
