If you're only planning to work on the cpp stuff, then just run './gradlew :cpp:check'. It's way faster and will test what you need. Daz
On 11 July 2013 14:35, Mitchell Mounts <mmou...@allstontrading.com> wrote: > Thank you for the information. By the way, I am trying to run the > developerBuild command to get running (before I have made any changes), and > I am consistently failing due to 3 performance tests: > > java.lang.AssertionError: Speed Results for test project 'small' with tasks > clean, build: we're slower than 1.6. > Difference: 551.6 ms slower (551.6 ms), 14.87%, max regression: 500 ms > Current Gradle avg: 4.261 s [4.296 s, 4.24 s, 4.2 s, 4.352 s, 4.217 s] > > min: 4.2 s, max: 4.352 s > Gradle 1.6 avg: 3.709 s [3.726 s, 3.736 s, 3.696 s, 3.697 s, 3.692 s] > > min: 3.692 s, max: 3.736 s > > > at > org.gradle.performance.fixture.PerformanceResults.assertCurrentVersionHasNotRegressed(PerformanceResults.groovy:85) > at org.gradle.performance.CleanBuildPerformanceTest.clean > build(CleanBuildPerformanceTest.groovy:40) > > java.lang.AssertionError: Memory Results for test project 'manyProjects' with > tasks help: we need more memory than 1.0. > Difference: 10.484 MB more (10992793.6 B), 14.14%, max regression: 10 MB > Current Gradle avg: 84.606 MB [84.475 MB, 85.334 MB, 84.394 MB, 84.441 MB, > 84.388 MB] > > min: 84.388 MB, max: 85.334 MB > Gradle 1.0 avg: 74.123 MB [74.186 MB, 74.032 MB, 73.932 MB, 74.245 MB, > 74.221 MB] > > min: 73.932 MB, max: 74.245 MB > > > at > org.gradle.performance.fixture.PerformanceResults.assertCurrentVersionHasNotRegressed(PerformanceResults.groovy:88) > at > org.gradle.performance.FirstBuildPerformanceTest.build(FirstBuildPerformanceTest.groovy:41) > > java.lang.AssertionError: Speed Results for test project 'small' with tasks > build: we're slower than 1.6. > Difference: 591 ms slower (591 ms), 17.50%, max regression: 500 ms > Current Gradle avg: 3.968 s [4.019 s, 4.125 s, 3.867 s, 3.936 s, 3.895 s] > > min: 3.867 s, max: 4.125 s > Gradle 1.6 avg: 3.377 s [3.364 s, 3.419 s, 3.36 s, 3.363 s, 3.381 s] > > min: 3.36 s, max: 3.419 s > > > at > org.gradle.performance.fixture.PerformanceResults.assertCurrentVersionHasNotRegressed(PerformanceResults.groovy:85) > at > org.gradle.performance.UpToDateBuildPerformanceTest.build(UpToDateBuildPerformanceTest.groovy:40) > > > It seems like they are close to their maximum threshold, but just over. Is > there a good way to get around this? > > Thanks, > > Mitchell > > > > On Thu, Jul 11, 2013 at 11:12 AM, Daz DeBoer < > darrell.deb...@gradleware.com> wrote: > >> Hi Mitchell >> It would be great if you were interested in doing some work on the CDT >> plugin. It's one part of the C++ support that isn't receiving any love at >> the moment, and it would cool if there was a 'champion' who could keep it >> up-to-date with all of the changes to C++ support, as well as adding >> missing IDE-specific features like build-paths. >> >> There is a design spec for the ongoing development of C++ support in >> Gradle: >> https://github.com/gradle/gradle/blob/master/design-docs/continuous-delivery-for-c-plus-plus.md. >> You'll notice the absence of any mention of CDT in there :). >> >> I'm currently working on extending the 'cpp' plugin to allow compilation >> of C and Assembly language sources. The C-language support is already in, >> and the Assembly stuff will be in soon. C compilation is done via GCC using >> the '-x c' option, so I think that should address the second feature you're >> looking at. A recent commit added a sample for how a C project could look ( >> https://github.com/gradle/gradle/tree/master/subprojects/docs/src/samples/cpp/c) >> which should be available in the next nightly build ( >> http://gradle.org/nightly). >> >> Let me know if you need any more pointers on how to proceed with >> improving the CDT support. I really appreciate your offer of assistance. >> Daz >> >> >> >> On 11 July 2013 09:52, Mitchell Mounts <mmou...@allstontrading.com>wrote: >> >>> Hello all, >>> >>> I am looking at contributing to gradle to help add more functionality to >>> it's eclipse-cdt and g++ support. Specifically, I want to add an option in >>> CDT to allow users to add build paths. I would also like to give users the >>> option to compile C code with the 'g++ -x c' option. >>> >>> I noticed that a recent commit to the cpp sub-project was entitled >>> 'Initial cut of support for compiling C sources,' and I am curious if this >>> actually removed the feature that I am proposing and if there is a specific >>> reason to avoid this path? >>> >>> For the cdt change, I have been looking at the source and it seems to me >>> that the change would have to be made in the CprojectDescriptor model. >>> >>> If there is anything else about gradle's C and CDT functionality that I >>> should be made aware of, please let me know! >>> >>> Thanks, >>> Mitchell >>> >>> ------------------------ >>> This message is for the named person(s) use only. It may contain >>> confidential proprietary or legally privileged information. No >>> confidentiality or privilege is waived or lost by any mistransmission. If >>> you receive this message in error, please immediately delete it and all >>> copies of it from your system, destroy any hard copies of it and notify the >>> sender. You must not, directly or indirectly use, disclose,distribute, >>> print, or copy any part of this message if you are not the intended >>> recipient. Allston Trading LLC and its subsidiaries and affiliates each >>> reserve the right to monitor all e-mail communications through its >>> networks. Any views expressed in this message are those of the individual >>> sender, except where the message states otherwise and the sender is >>> authorized to state them to be the views of any such entity. >>> ------------------------ >>> >> >> >> >> -- >> Darrell (Daz) DeBoer >> Principal Engineer, Gradleware >> http://www.gradleware.com >> > > > ------------------------ > This message is for the named person(s) use only. It may contain > confidential proprietary or legally privileged information. No > confidentiality or privilege is waived or lost by any mistransmission. If > you receive this message in error, please immediately delete it and all > copies of it from your system, destroy any hard copies of it and notify the > sender. You must not, directly or indirectly use, disclose,distribute, > print, or copy any part of this message if you are not the intended > recipient. Allston Trading LLC and its subsidiaries and affiliates each > reserve the right to monitor all e-mail communications through its > networks. Any views expressed in this message are those of the individual > sender, except where the message states otherwise and the sender is > authorized to state them to be the views of any such entity. > ------------------------ > -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com