On 25/07/2011, at 8:43 AM, Adam Murdoch wrote:
> 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 {
> // ...
> }
> }
> }
Agreed. The reason this wasn't done initially was because there was a
define-then-build kind of nature to the DSL, which didn't fit with the
container model but this has been resolved.
> 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.
I think the project name is a non starter. I still think “main” is the best
name. Using this project name as the output file name matches the java plugin,
so that's good.
> 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')
Not sure about .exe tbh, but I guess we do need some extension.
> 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
> }
The same for library? Seems like a nice optimisation for the simple case.
> 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 { ... }
> }
I've been trying to come up with a good name for this, and native was the best
I have come up with too.
My only concern with this is that it may be premature, if you are also implying
that we need to design (at this time) for multiple input languages to an
executable. That's going to add a lot of complexity we don't understand. But if
you are talking just about naming right now I can get on board with this.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
