On 26/07/2011, at 9:23 AM, Luke Daley wrote:
>
> 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.
This was just to demonstrate that the final output file is (or could be) a
computed value, that depends on a few things. I think we want ${project.name}
or ${project.name}.exe depending whether we are building for windows. And
lib${project.name}.so or ${project.name}.dll, and so on, for libraries.
>
>> 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.
We can also use this pattern to push the application plugin dsl towards
handling multiple applications:
Step 1:
application { ... some stuff about the application ... }
Step 2:
applications {
main { ... some stuff about the application ... }
anotherApp { ... }
}
or maybe, to be consistent with the native stuff:
jvm {
applications {
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 { ... }
>> }
>
>
> 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.
I think it's about naming. We know we need to support native binaries built
from things other than C++, so it would be nice if the DSL can reflect this.
Then, we can later add the support without messing too much with existing C++
builds.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
