Hi,
The C++ dsl generally looks good to me. It has all the stuff I'd expect.
However, I think we should tweak some things so that the c++ dsl and the
existing dsl are more consistent with each other. This might mean changes to
the existing dsl.
Looking at the high-level structure for defining an executable, we have
something like this (ignoring libraries for now, assuming they work the same
way):
cpp {
executable {
// creates and configures the 'main' executable
}
executable('someExe') {
// creates and configures the 'someExe' executable
}
executables.main {
// configures the 'main' executable (if it has already been added, by,
say, a plugin)
}
executables.someExe {
// configures the 'someExe' executable
}
}
I think it would be better if we change CppExecutableContainer to extend
NamedDomainObjectContainer and remove the factory methods from
CppProjectExtension. This way, we use a consistent dsl to managing a set of
domain objects with a name (consistent with project.sourceSets,
project.configurations, project.tasks, and project.cpp.sourceSets, with more on
the way)
cpp {
executables {
main {
// configure the main executable, creating it if not defined
}
someExe {
// ...
}
}
}
I'd also be tempted to use the project name as the default name for the
executable. But this is kind of awkward:
cpp {
executables {
myproject { ... }
someAdditionalExe { ... }
}
}
So, one option is to continue to use 'main' as the identifier for the default
executable, and the project name as the output file name. In fact, it might be
good to use the project name in the output file name of all executables. So:
cpp.executables.main.file.name == project.name (+ '.exe')
cpp.executables.custom.file.name == project.name + '-custom' (+ '.exe')
It might be also be good to add a convenience method for accessing the default
executable:
cpp {
executable { ... } // same as executables.main { ... }
executable // same as executables.main
}
I'd also like to keep the executables decoupled from C++, as we need to build
executables from many different languages (and combinations of languages). We
should model them as native executables, not C++ executables. To me, the fact
that C++ is used as an implementation language is an input to the executable,
and is not something fundamental to the executable. An executable might contain
any mix of implementation languages: C, C++, C#, objective-c, assembler, even
Java.
So, I think we should split CppProjectExtension into a C++ specific part, and a
native part that is language independent:
cpp {
sourceSets {... }
}
native {
executables { ... }
libraries { ... }
}
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
