>> What is "other compilers" here? Microsoft has historically seemingly had no
>> care to make their headers to be compatible with any other compiler other
>> than VS.
>> In the past I have attempted to do this, but the headers are so full of
>> VS-isms that it's impossible to use in any other compiler without
>> modifications, unless that compiler is strictly VS compliant, such as
>> Intel's on Windows.
>> So, that completely rules what comes to mind for me at least, which is
>> MinGW...
>
> Intel?
> There is also a recent effort to get LLVM - so clang/lld - integrated into
> Visual Studio, with support for Windows-specific code:
> http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html
>
I did mention Intel, but was not aware of LLVM's effort.
>> But I am against applying such filters automatically.
>> 1) we often use .cxx extensions for C++ files, and also .cc is another
>> commonly used one out in the wild.
>> 2) some generated code we have to deal with uses non default/standard
>> extensions (such as gSOAP and its .nsmap file) that needs to be compiled as
>> C/C++
>> So I'm of the opinion that anything in the source folders should be
>> automatically be treated as source, and the user can apply filters to
>> exclude what they need to be excluded specifically.
>
> The C++ source set could simply default to **/*.cpp + **/*.cxx + **/*.cc,
> which would cover the majority of uses.
> I believe it makes more sense to default to something relevant and useable by
> pretty much everybody without any single change, versus having everybody
> override the default settings to use the same excludes: **/*.h and possibly
> **/*.inc, in the current state...
>
This is coming to be a discussion in difference in practices. It's
only natural, since everyone does what they think is best, which is
often in disagreement with others.
Some projects intermix "compiled files" and "headers" within the same
tree, other projects split them into different subtrees.
Some projects intermix different languages of code within the same
tree, other projects split them into distinct subtrees.
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'
Projects I've worked on in the past, such as x264 [1] and libav [2]
both intermix headers and "compiled files" (C and asm) with the
"headers", though the asm source files have some semblance of
separation by being in architecture specific subfolders. Though in
both projects, x86_64 and x86 are within the same "architecture"
folder, due to the high similarity between the two.
This particularly style of layout is more 'localized' in that related
files are together, but makes publishing more difficult with having to
know which headers are private vs public.
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.
But I also believe there should be some consistency across gradle
itself, to avoid potential confusions when a project utilizing gradle
"branches out" in language usage, e.g. from java to native or the
reverse direction.
However, this may also be unavoidable with such large discrepancies in
nature of java-based languages and native ones.
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.
[1] git://git.videolan.org/x264.git
[2] git://git.libav.org/libav.git
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
