On Thu, Nov 28, 2013 at 9:42 AM, Michael Putters < michael.putt...@binarygenetics.com> wrote:
> From: Steven Walters [mailto:kemu...@gmail.com] > Sent: Thursday, November 28, 2013 5:42 PM > > > I typically utilize the practice of different subtrees, also utilizing > the 'private' vs 'public' header concepts to keep the organization more > straightforward. > > This particularly style of layout makes publishing extremely simplified, > but the code overall is a bit less 'localized' > > That's actually what I use for my projects (and the one I'm migrating to > Gradle): > > - a directory for "public" headers > - a directory for "private" headers > - a directory for source files > > But with the current Gradle setup, that can't be done. So maybe a first > step - rather than adding filters - would be to add a third set of files > next to the sources and exported headers. > This might actually solve the resource.h "issue" as well... > > The only downside I can think of with such a setup is that there is no > simple way to control the visibility of the "private" headers for each > language. If you have this: > > /src/main/cpp > /src/main/objc > /src/main/privateheaders > > It's a poor example, but what if your private headers shouldn't be an > include path for the objc source set? Then again, since I'm having > difficulties thinking of a better example, maybe it just doesn't matter... > > And maybe it could be /include replacing /headers, and /shared for > /privateheaders, because after all it would end up being something other > than headers, just a "shared between source sets" set. > > > As slightly mentioned, there are pros and cons to each of the layout > styles, but gradle has to default in some manner and should have ways of > supporting the difference in practices and not make using other ways too > cumbersome. > > In the end, the discussion needs to be continued before rushing to a > particular decision, allowing for a system that everyone can utilize with > ease. > 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? 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