From: Steven Walters [mailto:[email protected]]
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.
I expect that's one of the purposes of this mailing list :)
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
