Cpp plugin source file location conventions feel wrong

Old Forum Archive
1

I am fairly new to gradle. Being a person that works primarily in C++, the current conventions (for 1.7rc1) seem out-of-touch.

From what I can tell, the default convention is (please correct me if I’m wrong):

parent_directory
    build.gradle
    src
        ${projectname}
            cpp
                file.cpp
            headers
                file.h

C++ doesn’t require such a structured heirarchy like Java does. There are some commonly used heirarchies however:

${projectname}
    [build_script_or_config]
    src
        file.cpp
        private_header.h
    include
        ${projectname}
            file.h

Where the ‘src’ and ‘include/${projectname}’ directories might very well contain other directories (sometimes roughly mapping to namespaces.

Others just keep the source code flat or place the build script in a sibling directory.

Is there a rationale for the current convention (other than, “It makes it more like Java”)?

2

I guess I should explain my problem… how can I make these patterns that appear more often work correctly?

3

Java doesn’t need such a hierarchy either. The challenge is to find a convention that works for a mix of Java, C++, and arbitrary other languages, in the same project. Of course, all of this is reconfigurable.

4

The C++ stuff is a work in progress, and we plan to make it easy for you to just grab the language support and define your own conventions. In ‘gradle-1.7-rc-1’, you should be able to handle your proposed source layout like:

cpp {
    sourceSets {
        main {
            source {
                srcDir "src"
                include "**/*.cpp"
            }
            // Gradle currently has no concept of 'private' headers
            exportedHeaders {
                srcDir "src"
                // There no convenient way to include headers recursively (this is a bug)
                srcDirs "include/project1", "include/project2"
         }
    }
}

Note that in ‘gradle-1.8’ (latest nightly) the syntax has changed slightly to: sources {

main {

cpp {

source {

srcDir … etc </code

5

One more point: there are already ways for gradle to automatically download the dependency header files to include when building your project, so you shouldn’t need to include them in your source tree. This is also true in the case of a multi-project build.

Check out the ‘cpp/dependencies’ and ‘cpp/multi-build’ samples.

In the future we plan to make this a lot more convenient.

6

And finally: I’ve just fixed the bug that prevented recursive inclusion of header files, so with the next gradle nightly you should be able to do: sources {

main {

cpp {

source {

srcDir “src”

include “**/*.cpp”

}

exportedHeaders {

srcDirs “src”, “include”

include “**/*.h”

}

} }

7

One more point: there are already ways for gradle to automatically download the dependency header files to include when building your project, so you shouldn’t need to include them in your source tree. This is also true in the case of a multi-project build. >>> >>>Check out the cpp/dependencies and cpp/multi-build samples. >>> >>>In the future we plan to make this a lot more convenient.

I think this misses the point. Those aren’t header files that are external. They are the header files for the current project. Are you also saying that in a multi-project build, the tool will copy header files from one directory to another if there are project-to-project dependencies? That would be an awful waste of resources, and make the build extremely slow. It is not unusual for a .cpp file to recursively #include 100s if not 1000s of header files.

8

No I’m not saying that the header files will be copied. I’m saying that they will be included. If they are external they will be downloaded, unzipped and included; if they are available in another project then they will be included directly.

You can see this happening in the samples I mentioned earlier: ‘cpp/dependencies’ and ‘cpp/multi-project’.

Thanks for the feedback. Remember that this is a work in progress, and many features are still to be implemented. Getting input from experienced C++ devs like yourself can really help us to shape the C++ support in Gradle to be something great.

If you’re interested in the current development plans, you might want to read the design spec.