> 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"
#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...
#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.
> 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
