Google Test Support

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Google Test Support

Daniel Lacasse
I want to kick start the discussion for contributing support for the Google Test framework support. I have identified 3 stories which should give Gradle a functional support for Google Test.

Story: Specific class type for CUnit binary
This story makes sure that subsequent test framework are discriminated.
 - Add class org.gradle.nativebinaries.test.cunit.CUnitTestSuiteExecutableBinary which extends from TestSuiteExecutableBinary

User visible change
 - Backward compatibility is kept and the following configure all test suite binary regardless of there framework.
   binaries.withType(TestSuiteExecutableBinary) {
     // Target all test binaries
   }
 - It will now be possible to configure the CUnit test suite binary individually like this:
   binaries.withType(CUnitTestSuiteExecutableBinary) {
     // Target only CUnit binaries
   }

Test cases
apply 'cunit'
model { testSuites { mainTest { binaires.all { assert it instanceof CUnitTestSuiteExecutableBinary } } } }


Story: RunTestExecutable can take arguments
This story make it possible to passed arguments to the test binary. Espacially useful for more advance test framework like Google Test.

User visible change
 - tasks.withType(RunTestExecutable).all {
    testArgs '--args-to-pass', '-v'
   }

Open issues
 - Is testArgs a good name for the property on the RunTestExecutable task.


Story: Google Test support
This story adds support for the Google Test framework.

Note that the implementation is highly based on the current CUnit implementation.
 - Add class org.gradle.nativebinaries.test.googletest.GoogleTestTestSuite
 - Add class org.gradle.nativebinaires.test.googletest.GoogleTestTestSuiteExecutableBinary
 - Add class org.gradle.nativebinaires.test.googletest.plugins.GoogleTestPlugin
 - Add class org.gradle.nativebinaires.test.googletest.internal.DefaultGoogleTestTestSuite
 - Add class org.gradle.nativebinaires.test.googletest.internal.ConfigureGoogleTestTestSources
 - Add class org.gradle.nativebinaires.test.googletest.internal.CreateGoogleTestBinaries
 
Open issues
 - Should the package name be 'googletest' or 'gtest' ('gtest' is used for there include namespace in c++)?
 - Should the C++ source set for Google Test named 'googletest' or 'gtest'?
 - How can we refactor CUnit code for reusability with Google Test? The process is the same - configure test source, create binaries, etc. - but yet different.

--
Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Google Test Support

Russel Winder-3
On Mon, 2014-06-16 at 16:06 -0700, Daniel Lacasse wrote:
> I want to kick start the discussion for contributing support for the Google
> Test framework support. I have identified 3 stories which should give
> Gradle a functional support for Google Test.
[…]

Are people still using frameworks such as Boost.Test and GoogleTest? I
thought C++ codes had long since moved to header only frameworks such as
CUTE and Catch.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

RE: Google Test Support

Michael Putters
Many projects use Boost.Test and GoogleTest (and I'm one of those users, so I'd certainly be happy with GoogleTest support, as I was already thinking about adding such support once the CUnit part was stable).

But I doubt there is an easy way to figure out the %age of projects using each test framework (and a relatively coherent method of finding such information was available, it wouldn't take into account the numerous closed source projects).

Anyway Daniel, if you need help and/or a tester, feel free to drop me an e-mail ;-)


Michael

-----Original Message-----
From: Russel Winder [mailto:[hidden email]]
Sent: Tuesday, June 17, 2014 8:38 AM
To: [hidden email]
Subject: Re: [gradle-dev] Google Test Support

On Mon, 2014-06-16 at 16:06 -0700, Daniel Lacasse wrote:
> I want to kick start the discussion for contributing support for the
> Google Test framework support. I have identified 3 stories which
> should give Gradle a functional support for Google Test.
[…]

Are people still using frameworks such as Boost.Test and GoogleTest? I thought C++ codes had long since moved to header only frameworks such as CUTE and Catch.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

RE: Google Test Support

Daniel Lacasse
In reply to this post by Daniel Lacasse
Thanks Michael. I will certainly notice you once we get this going. I already did a quick implementation of Google Test but it's mainly a copy of the cunit. I really want a better implementation for this.

@Russel: The framework you are pointing looks really promising but unfortunately we are also user of Google Test. Maybe in the future we could see contribution for those frameworks.

---
Daniel
On Tuesday, June 17, 2014 02:49 AM, Michael Putters <[hidden email]> wrote:

Many projects use Boost.Test and GoogleTest (and I'm one of those users, so I'd certainly be happy with GoogleTest support, as I was already thinking about adding such support once the CUnit part was stable).

But I doubt there is an easy way to figure out the %age of projects using each test framework (and a relatively coherent method of finding such information was available, it wouldn't take into account the numerous closed source projects).

Anyway Daniel, if you need help and/or a tester, feel free to drop me an e-mail ;-)


Michael

-----Original Message-----
From: Russel Winder [mailto:[hidden email]]
Sent: Tuesday, June 17, 2014 8:38 AM
To: [hidden email]
Subject: Re: [gradle-dev] Google Test Support

On Mon, 2014-06-16 at 16:06 -0700, Daniel Lacasse wrote:
> I want to kick start the discussion for contributing support for the
> Google Test framework support. I have identified 3 stories which
> should give Gradle a functional support for Google Test.
[…]

Are people still using frameworks such as Boost.Test and GoogleTest? I thought C++ codes had long since moved to header only frameworks such as CUTE and Catch.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:[hidden email]
41 Buckmaster Road m: +44 7770 465 077 xmpp: [hidden email]
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Reply | Threaded
Open this post in threaded view
|

Re: Google Test Support

Russel Winder-3
On Tue, 2014-06-17 at 10:37 +0000, Daniel Lacasse wrote:
[…]
> @Russel: The framework you are pointing looks really promising but
> unfortunately we are also user of Google Test. Maybe in the future we
> could see contribution for those frameworks.

CUTE is from Peter Somerlad (*) and his people. There is an Eclipse
plugin. Also SConsolidator so you can use SCons in Eclipse instead of
Make. Is there a Gradle capability in that space?

Catch is by Phil Nash with contributions from others. It builds on
foundations such as Aeryn, GoogleTest, Cucumber, CUTE, etc.  Phil is a
hardcore ACCU conference person (**).


(*) Peter is on the C++ standards committee and a regular at ACCU
conferences (**)

(**) http://accu.org. Tends to be where lots of hardcore C++ folk hang
out. if Gradle is to be taken seriously in the C++ space, Gradleware
should have a technical marketing presence at ACCU conferences.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Google Test Support

Adam Murdoch
In reply to this post by Daniel Lacasse

On 16 Jun 2014, at 4:06 pm, Daniel Lacasse <[hidden email]> wrote:

I want to kick start the discussion for contributing support for the Google Test framework support. I have identified 3 stories which should give Gradle a functional support for Google Test.

Thanks for writing this up. It would be great to see this addition to the native support. More comments below.


Story: Specific class type for CUnit binary
This story makes sure that subsequent test framework are discriminated.
 - Add class org.gradle.nativebinaries.test.cunit.CUnitTestSuiteExecutableBinary which extends from TestSuiteExecutableBinary

User visible change
 - Backward compatibility is kept and the following configure all test suite binary regardless of there framework.
   binaries.withType(TestSuiteExecutableBinary) {
     // Target all test binaries
   }
 - It will now be possible to configure the CUnit test suite binary individually like this:
   binaries.withType(CUnitTestSuiteExecutableBinary) {
     // Target only CUnit binaries
   }

Test cases
apply 'cunit'
model { testSuites { mainTest { binaires.all { assert it instanceof CUnitTestSuiteExecutableBinary } } } }


Story: RunTestExecutable can take arguments
This story make it possible to passed arguments to the test binary. Espacially useful for more advance test framework like Google Test.

User visible change
 - tasks.withType(RunTestExecutable).all {
    testArgs '--args-to-pass', '-v'
   }

Open issues
 - Is testArgs a good name for the property on the RunTestExecutable task.

It would be good to sync up with the Exec/JavaExec/Test tasks in some way, even if it’s to use the same naming scheme for the methods that specify args.

We don’t want to implement ExecSpec directly, I think, as things like specifying the executable doesn’t make any sense here. Perhaps we should extract some interfaces from ExecSpec that we can share here and with the Exec task.



Story: Google Test support
This story adds support for the Google Test framework.

Note that the implementation is highly based on the current CUnit implementation.
 - Add class org.gradle.nativebinaries.test.googletest.GoogleTestTestSuite
 - Add class org.gradle.nativebinaires.test.googletest.GoogleTestTestSuiteExecutableBinary
 - Add class org.gradle.nativebinaires.test.googletest.plugins.GoogleTestPlugin
 - Add class org.gradle.nativebinaires.test.googletest.internal.DefaultGoogleTestTestSuite
 - Add class org.gradle.nativebinaires.test.googletest.internal.ConfigureGoogleTestTestSources
 - Add class org.gradle.nativebinaires.test.googletest.internal.CreateGoogleTestBinaries
 
Open issues
 - Should the package name be 'googletest' or 'gtest' ('gtest' is used for there include namespace in c++)?

I don’t have a strong opinion here.

 - Should the C++ source set for Google Test named 'googletest' or 'guest'?

I think it should probably be the same as the above.

 - How can we refactor CUnit code for reusability with Google Test? The process is the same - configure test source, create binaries, etc. - but yet different.

Eventually, I think we want to have some way for the plugin to register a new test suite type and corresponding test implementation. Some base plugin would then take care of wiring all the stuff together.

Not exactly sure how this would look yet. We need to do something similar for plugins that add language support, so we could wait and see how that looks and reuse the same approach for plugins that add test execution capabilities.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: Google Test Support

Adam Murdoch
In reply to this post by Russel Winder-3

On 17 Jun 2014, at 4:14 am, Russel Winder <[hidden email]> wrote:

On Tue, 2014-06-17 at 10:37 +0000, Daniel Lacasse wrote:
[…]
@Russel: The framework you are pointing looks really promising but
unfortunately we are also user of Google Test. Maybe in the future we
could see contribution for those frameworks.

CUTE is from Peter Somerlad (*) and his people. There is an Eclipse
plugin. Also SConsolidator so you can use SCons in Eclipse instead of
Make. Is there a Gradle capability in that space?

Not yet. Gradle can generate the configuration files for CDT, but this support is pretty basic.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

RE: Google Test Support

Daniel Lacasse
In reply to this post by Daniel Lacasse
Thanks Adam for your insight. I will start with synching up the naming convention with the current Exec task and see how we can extract common interface later.

As for the name used for package and source set , I will use googletest as it's more descriptive in the code.

Finally, I see what you mean about having some kind of base plugin to register test suite but I will hold off until the integration is finished.

I will start moving forward with this.

---
Daniel
On Tuesday, June 17, 2014 04:28 PM, Adam Murdoch <[hidden email]> wrote:


On 16 Jun 2014, at 4:06 pm, Daniel Lacasse < [hidden email]> wrote:

I want to kick start the discussion for contributing support for the Google Test framework support. I have identified 3 stories which should give Gradle a functional support for Google Test.

Thanks for writing this up. It would be great to see this addition to the native support. More comments below.


Story: Specific class type for CUnit binary
This story makes sure that subsequent test framework are discriminated.
 - Add class org.gradle.nativebinaries.test.cunit.CUnitTestSuiteExecutableBinary which extends from TestSuiteExecutableBinary

User visible change
 - Backward compatibility is kept and the following configure all test suite binary regardless of there framework.
   binaries.withType(TestSuiteExecutableBinary) {
     // Target all test binaries
   }
 - It will now be possible to configure the CUnit test suite binary individually like this:
   binaries.withType(CUnitTestSuiteExecutableBinary) {
     // Target only CUnit binaries
   }

Test cases
apply 'cunit'
model { testSuites { mainTest { binaires.all { assert it instanceof CUnitTestSuiteExecutableBinary } } } }


Story: RunTestExecutable can take arguments
This story make it possible to passed arguments to the test binary. Espacially useful for more advance test framework like Google Test.

User visible change
 - tasks.withType(RunTestExecutable).all {
    testArgs '--args-to-pass', '-v'
   }

Open issues
 - Is testArgs a good name for the property on the RunTestExecutable task.

It would be good to sync up with the Exec/JavaExec/Test tasks in some way, even if it’s to use the same naming scheme for the methods that specify args.

We don’t want to implement ExecSpec directly, I think, as things like specifying the executable doesn’t make any sense here. Perhaps we should extract some interfaces from ExecSpec that we can share here and with the Exec task.



Story: Google Test support
This story adds support for the Google Test framework.

Note that the implementation is highly based on the current CUnit implementation.
 - Add class org.gradle.nativebinaries.test.googletest.GoogleTestTestSuite
 - Add class org.gradle.nativebinaires.test.googletest.GoogleTestTestSuiteExecutableBinary
 - Add class org.gradle.nativebinaires.test.googletest.plugins.GoogleTestPlugin
 - Add class org.gradle.nativebinaires.test.googletest.internal.DefaultGoogleTestTestSuite
 - Add class org.gradle.nativebinaires.test.googletest.internal.ConfigureGoogleTestTestSources
 - Add class org.gradle.nativebinaires.test.googletest.internal.CreateGoogleTestBinaries
 
Open issues
 - Should the package name be 'googletest' or 'gtest' ('gtest' is used for there include namespace in c++)?

I don’t have a strong opinion here.

 - Should the C++ source set for Google Test named 'googletest' or 'guest'?

I think it should probably be the same as the above.

 - How can we refactor CUnit code for reusability with Google Test? The process is the same - configure test source, create binaries, etc. - but yet different.

Eventually, I think we want to have some way for the plugin to register a new test suite type and corresponding test implementation. Some base plugin would then take care of wiring all the stuff together.

Not exactly sure how this would look yet. We need to do something similar for plugins that add language support, so we could wait and see how that looks and reuse the same approach for plugins that add test execution capabilities.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: Google Test Support

Adam Murdoch

On 18 Jun 2014, at 7:19 pm, Daniel Lacasse <[hidden email]> wrote:

Thanks Adam for your insight. I will start with synching up the naming convention with the current Exec task and see how we can extract common interface later.

As for the name used for package and source set , I will use googletest as it's more descriptive in the code.

Finally, I see what you mean about having some kind of base plugin to register test suite but I will hold off until the integration is finished.

This is a good plan.


I will start moving forward with this.

---
Daniel

On Tuesday, June 17, 2014 04:28 PM, Adam Murdoch <[hidden email]> wrote:


On 16 Jun 2014, at 4:06 pm, Daniel Lacasse < [hidden email]> wrote:

I want to kick start the discussion for contributing support for the Google Test framework support. I have identified 3 stories which should give Gradle a functional support for Google Test.

Thanks for writing this up. It would be great to see this addition to the native support. More comments below.


Story: Specific class type for CUnit binary
This story makes sure that subsequent test framework are discriminated.
 - Add class org.gradle.nativebinaries.test.cunit.CUnitTestSuiteExecutableBinary which extends from TestSuiteExecutableBinary

User visible change
 - Backward compatibility is kept and the following configure all test suite binary regardless of there framework.
   binaries.withType(TestSuiteExecutableBinary) {
     // Target all test binaries
   }
 - It will now be possible to configure the CUnit test suite binary individually like this:
   binaries.withType(CUnitTestSuiteExecutableBinary) {
     // Target only CUnit binaries
   }

Test cases
apply 'cunit'
model { testSuites { mainTest { binaires.all { assert it instanceof CUnitTestSuiteExecutableBinary } } } }


Story: RunTestExecutable can take arguments
This story make it possible to passed arguments to the test binary. Espacially useful for more advance test framework like Google Test.

User visible change
 - tasks.withType(RunTestExecutable).all {
    testArgs '--args-to-pass', '-v'
   }

Open issues
 - Is testArgs a good name for the property on the RunTestExecutable task.

It would be good to sync up with the Exec/JavaExec/Test tasks in some way, even if it’s to use the same naming scheme for the methods that specify args.

We don’t want to implement ExecSpec directly, I think, as things like specifying the executable doesn’t make any sense here. Perhaps we should extract some interfaces from ExecSpec that we can share here and with the Exec task.



Story: Google Test support
This story adds support for the Google Test framework.

Note that the implementation is highly based on the current CUnit implementation.
 - Add class org.gradle.nativebinaries.test.googletest.GoogleTestTestSuite
 - Add class org.gradle.nativebinaires.test.googletest.GoogleTestTestSuiteExecutableBinary
 - Add class org.gradle.nativebinaires.test.googletest.plugins.GoogleTestPlugin
 - Add class org.gradle.nativebinaires.test.googletest.internal.DefaultGoogleTestTestSuite
 - Add class org.gradle.nativebinaires.test.googletest.internal.ConfigureGoogleTestTestSources
 - Add class org.gradle.nativebinaires.test.googletest.internal.CreateGoogleTestBinaries
 
Open issues
 - Should the package name be 'googletest' or 'gtest' ('gtest' is used for there include namespace in c++)?

I don’t have a strong opinion here.

 - Should the C++ source set for Google Test named 'googletest' or 'guest'?

I think it should probably be the same as the above.

 - How can we refactor CUnit code for reusability with Google Test? The process is the same - configure test source, create binaries, etc. - but yet different.

Eventually, I think we want to have some way for the plugin to register a new test suite type and corresponding test implementation. Some base plugin would then take care of wiring all the stuff together.

Not exactly sure how this would look yet. We need to do something similar for plugins that add language support, so we could wait and see how that looks and reuse the same approach for plugins that add test execution capabilities.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: "Native Support" [was Google Test Support]

Russel Winder-3
In reply to this post by Adam Murdoch
On Tue, 2014-06-17 at 13:28 -0700, Adam Murdoch wrote:
[…]
> Thanks for writing this up. It would be great to see this addition to the native support. More comments below.
[…]

Quick sanity check: people are using the term "native support" but isn't
what people mean here "C and C++ support". Native code languages such as
Go, D, Rust have very, very, very different approaches to build compared
to C and C++ (*, **).


(*) Though Haskell and OCaml are quite similar to C and C++.

(**) How D is build can often depend on whether the total system is a
mixed language C, C++, D one.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: "Native Support" [was Google Test Support]

Daz DeBoer-2

On Thu, Jun 19, 2014 at 8:59 AM, Russel Winder <[hidden email]> wrote:
On Tue, 2014-06-17 at 13:28 -0700, Adam Murdoch wrote:
[…]
> Thanks for writing this up. It would be great to see this addition to the native support. More comments below.
[…]

Quick sanity check: people are using the term "native support" but isn't
what people mean here "C and C++ support".

Yes, we're using the term 'native' as a not very good descriptor for the Gradle support for building applications in C, C++, Assembler, Objective-C, Objective-C++ and Windows Resources. Unfortunately, we haven't come up with a better term to describe this set of functionality
 
Native code languages such as
Go, D, Rust have very, very, very different approaches to build compared
to C and C++ (*, **).

Can you elaborate a little on this? Is it the way the source code is built into a binary that is different, or the type of output that is created, or both? Where does Assembler fall into this mix?

Do these other languages as a group follow a consistent pattern, or are they each fundamentally different from each other?

Thanks for any overview you could give.

Daz
Reply | Threaded
Open this post in threaded view
|

Re: "Native Support" [was Google Test Support]

Russel Winder-3
On Thu, 2014-06-19 at 12:13 -0700, Daz DeBoer wrote:
[…]
> Yes, we're using the term 'native' as a not very good descriptor for the
> Gradle support for building applications in C, C++, Assembler, Objective-C,
> Objective-C++ and Windows Resources. Unfortunately, we haven't come up with
> a better term to describe this set of functionality
[…]

It all depends if the same infrastructure covers just them or all
languages resulting in native code!

> Can you elaborate a little on this? Is it the way the source code is built
> into a binary that is different, or the type of output that is created, or
> both? Where does Assembler fall into this mix?

Sorry, but… it depends.

So for example, with Chapel you always try to compile all the source
with a single compile command generating the executable directly without
generating any intermediate "semi-compiled" files.  D is also compiled
in this way by preference. However D can also be compiled in the classic
C++ approach of compile each source file into an object file and then
link all the objects together to create the executable.

As for assembly language, no applications programmer should ever have to
use it!

> Do these other languages as a group follow a consistent pattern, or are
> they each fundamentally different from each other?

Well they are all fundamentally the same in that they generate native
code :-)

In the end it all depends how you are tracking compilation products. I
haven't yet tried the Gradle support for this as I am currently fighting
with Autotools (I thought I had left this behind years ago), and working
with Dub, SCons, Waf and (but only if I really, really have to) CMake.

Someone on the Gradle native code team needs to write a short article
saying what Gradle beats Dub, SCons, Waf and CMake. If this argument
cannot be made convincingly then Gradle will have no future in the wider
world of native code build. From experience it is hard enough weaning
people off Make, and introducing Python is a battle. I suspect
introducing JVM is going to be an even bigger battle than introducing
PVM.


--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: "Native Support" [was Google Test Support]

Steven Walters
On Fri, Jun 20, 2014 at 8:54 AM, Russel Winder <[hidden email]> wrote:
>
> As for assembly language, no applications programmer should ever have to
> use it!

Assembly always has a place, and that place more commonly appears in
maximizing speed/performance.
This is more frequent in applications that have a heavy mathematical
background/focus.
statistics/scientific analysis, and video/audio processing are some
examples of this.

>
> Someone on the Gradle native code team needs to write a short article
> saying what Gradle beats Dub, SCons, Waf and CMake. If this argument
> cannot be made convincingly then Gradle will have no future in the wider
> world of native code build. From experience it is hard enough weaning
> people off Make, and introducing Python is a battle. I suspect
> introducing JVM is going to be an even bigger battle than introducing
> PVM.

I say that Gradle's (initial?) target audience for the native code
support is not development teams that deal purely in native code.
It'll be harder to convince them away from what they've been used to
for years and it "works" enough for them.
That is more summarily, those teams don't have a pain point that needs
resolving.

Instead Gradle's first goal should be targeting teams/"houses" that
deal in a mixture of jvm and non-jvm based languages.
In my opinion, this is because there isn't much in a good single
solution for dealing with the combination of all of them.
Often needing different build systems/frameworks to try and smudge
together some final result.
Or teams developing something in house to try and handle it more
gracefully (but then the maintenance!)

E.g. at my work, we are a multi-language house from being heavy in
both PLM/PDM and CAD, so we're consistently dealing with all of Java,
C, C++, and C#.
Being able to use only a single build system to handle everything
would be such a blessing and simplification of the mess that is the
current state of things.
That is, it would solve the pain point we've had for a rather long time.

Regards,
Steven

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: "Native Support" [was Google Test Support]

Russel Winder-3
On Sat, 2014-06-21 at 12:01 -0400, Steven Walters wrote:

> On Fri, Jun 20, 2014 at 8:54 AM, Russel Winder <[hidden email]> wrote:
> >
> > As for assembly language, no applications programmer should ever have to
> > use it!
>
> Assembly always has a place, and that place more commonly appears in
> maximizing speed/performance.
> This is more frequent in applications that have a heavy mathematical
> background/focus.
> statistics/scientific analysis, and video/audio processing are some
> examples of this.

Those assembly language bits should be in libraries rather than
applications though. But I agree there is an important role for assembly
language in performance oriented systems. And operating systems for
things like context switching.

> > Someone on the Gradle native code team needs to write a short article
> > saying what Gradle beats Dub, SCons, Waf and CMake. If this argument
> > cannot be made convincingly then Gradle will have no future in the wider
> > world of native code build. From experience it is hard enough weaning
> > people off Make, and introducing Python is a battle. I suspect
> > introducing JVM is going to be an even bigger battle than introducing
> > PVM.
>
> I say that Gradle's (initial?) target audience for the native code
> support is not development teams that deal purely in native code.
> It'll be harder to convince them away from what they've been used to
> for years and it "works" enough for them.
> That is more summarily, those teams don't have a pain point that needs
> resolving.
>
> Instead Gradle's first goal should be targeting teams/"houses" that
> deal in a mixture of jvm and non-jvm based languages.
> In my opinion, this is because there isn't much in a good single
> solution for dealing with the combination of all of them.
> Often needing different build systems/frameworks to try and smudge
> together some final result.
> Or teams developing something in house to try and handle it more
> gracefully (but then the maintenance!)
>
> E.g. at my work, we are a multi-language house from being heavy in
> both PLM/PDM and CAD, so we're consistently dealing with all of Java,
> C, C++, and C#.
> Being able to use only a single build system to handle everything
> would be such a blessing and simplification of the mess that is the
> current state of things.
> That is, it would solve the pain point we've had for a rather long time.

There are a number of people using SCons in the mixed Java/C++ space. I
keep saying they should use Gradle, but… they keep wanting to fix SCons.
This is fine but I think it will be hard.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

RE: "Native Support" [was Google Test Support]

Michael Putters
In reply to this post by Steven Walters
Right now Gradle doesn't add all that much vs existing solutions, but I'm hoping I'll eventually be able to easily deploy my dependencies in a Maven repository and stop having everybody in a team build each library we use with whatever build system they require (which is always a different one, obviously).

Of course it's trickier than with Java (due to all the variants of the same library: architecture, operating system, debug/release, etc.), but even the ability to just register pre-built native libraries as Maven artifacts would do wonders...

-----Original Message-----
From: Steven Walters [mailto:[hidden email]]
Sent: Saturday, June 21, 2014 6:02 PM
To: [hidden email]
Subject: Re: [gradle-dev] "Native Support" [was Google Test Support]

On Fri, Jun 20, 2014 at 8:54 AM, Russel Winder <[hidden email]> wrote:
>
> As for assembly language, no applications programmer should ever have
> to use it!

Assembly always has a place, and that place more commonly appears in maximizing speed/performance.
This is more frequent in applications that have a heavy mathematical background/focus.
statistics/scientific analysis, and video/audio processing are some examples of this.

>
> Someone on the Gradle native code team needs to write a short article
> saying what Gradle beats Dub, SCons, Waf and CMake. If this argument
> cannot be made convincingly then Gradle will have no future in the
> wider world of native code build. From experience it is hard enough
> weaning people off Make, and introducing Python is a battle. I suspect
> introducing JVM is going to be an even bigger battle than introducing
> PVM.

I say that Gradle's (initial?) target audience for the native code support is not development teams that deal purely in native code.
It'll be harder to convince them away from what they've been used to for years and it "works" enough for them.
That is more summarily, those teams don't have a pain point that needs resolving.

Instead Gradle's first goal should be targeting teams/"houses" that deal in a mixture of jvm and non-jvm based languages.
In my opinion, this is because there isn't much in a good single solution for dealing with the combination of all of them.
Often needing different build systems/frameworks to try and smudge together some final result.
Or teams developing something in house to try and handle it more gracefully (but then the maintenance!)

E.g. at my work, we are a multi-language house from being heavy in both PLM/PDM and CAD, so we're consistently dealing with all of Java, C, C++, and C#.
Being able to use only a single build system to handle everything would be such a blessing and simplification of the mess that is the current state of things.
That is, it would solve the pain point we've had for a rather long time.

Regards,
Steven

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: "Native Support" [was Google Test Support]

Adam Murdoch
In reply to this post by Steven Walters

On 22 Jun 2014, at 2:01 am, Steven Walters <[hidden email]> wrote:

On Fri, Jun 20, 2014 at 8:54 AM, Russel Winder <[hidden email]> wrote:

As for assembly language, no applications programmer should ever have to
use it!

Assembly always has a place, and that place more commonly appears in
maximizing speed/performance.
This is more frequent in applications that have a heavy mathematical
background/focus.
statistics/scientific analysis, and video/audio processing are some
examples of this.


Someone on the Gradle native code team needs to write a short article
saying what Gradle beats Dub, SCons, Waf and CMake. If this argument
cannot be made convincingly then Gradle will have no future in the wider
world of native code build. From experience it is hard enough weaning
people off Make, and introducing Python is a battle. I suspect
introducing JVM is going to be an even bigger battle than introducing
PVM.

I say that Gradle's (initial?) target audience for the native code
support is not development teams that deal purely in native code.
It'll be harder to convince them away from what they've been used to
for years and it "works" enough for them.
That is more summarily, those teams don't have a pain point that needs
resolving.

Instead Gradle's first goal should be targeting teams/"houses" that
deal in a mixture of jvm and non-jvm based languages.
In my opinion, this is because there isn't much in a good single
solution for dealing with the combination of all of them.

This is exactly the plan. Our goal with the native support at this stage is to make life better for those organisations that produce software for a bunch of different platforms, such as for the jvm, android, the native runtime, and javascript (as byte code for the web - not just the language). Using a single tool to provide a consistent interface, conventions and workflow for development is important for these teams. For most teams these days, building, verifying and releasing software is much more than just ‘build my jar’ or ‘link my binary’.

One thing that is missing from the Gradle story at the moment is dependency management that works across all these domains. This is something we’re working on at the moment.

For Gradle to be a realistic option for teams that develop native software only, we need to do something about performance - we need to make configuration time much faster, and we need to push parallel execution more. We’ve started on improving configuration time and this should lead to better paralysation too.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: "Native Support" [was Google Test Support]

Adam Murdoch
In reply to this post by Michael Putters

On 22 Jun 2014, at 4:26 am, Michael Putters <[hidden email]> wrote:

Right now Gradle doesn't add all that much vs existing solutions, but I'm hoping I'll eventually be able to easily deploy my dependencies in a Maven repository and stop having everybody in a team build each library we use with whatever build system they require (which is always a different one, obviously).

Of course it's trickier than with Java (due to all the variants of the same library: architecture, operating system, debug/release, etc.), but even the ability to just register pre-built native libraries as Maven artifacts would do wonders…

We’re working on full dependency management for native binaries. This will certainly include publishing and resolving binaries from a binary repository.



-----Original Message-----
From: Steven Walters [[hidden email]]
Sent: Saturday, June 21, 2014 6:02 PM
To: [hidden email]
Subject: Re: [gradle-dev] "Native Support" [was Google Test Support]

On Fri, Jun 20, 2014 at 8:54 AM, Russel Winder <[hidden email]> wrote:

As for assembly language, no applications programmer should ever have
to use it!

Assembly always has a place, and that place more commonly appears in maximizing speed/performance.
This is more frequent in applications that have a heavy mathematical background/focus.
statistics/scientific analysis, and video/audio processing are some examples of this.


Someone on the Gradle native code team needs to write a short article
saying what Gradle beats Dub, SCons, Waf and CMake. If this argument
cannot be made convincingly then Gradle will have no future in the
wider world of native code build. From experience it is hard enough
weaning people off Make, and introducing Python is a battle. I suspect
introducing JVM is going to be an even bigger battle than introducing
PVM.

I say that Gradle's (initial?) target audience for the native code support is not development teams that deal purely in native code.
It'll be harder to convince them away from what they've been used to for years and it "works" enough for them.
That is more summarily, those teams don't have a pain point that needs resolving.

Instead Gradle's first goal should be targeting teams/"houses" that deal in a mixture of jvm and non-jvm based languages.
In my opinion, this is because there isn't much in a good single solution for dealing with the combination of all of them.
Often needing different build systems/frameworks to try and smudge together some final result.
Or teams developing something in house to try and handle it more gracefully (but then the maintenance!)

E.g. at my work, we are a multi-language house from being heavy in both PLM/PDM and CAD, so we're consistently dealing with all of Java, C, C++, and C#.
Being able to use only a single build system to handle everything would be such a blessing and simplification of the mess that is the current state of things.
That is, it would solve the pain point we've had for a rather long time.

Regards,
Steven

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: "Native Support" [was Google Test Support]

Adam Murdoch
In reply to this post by Russel Winder-3

On 20 Jun 2014, at 10:54 pm, Russel Winder <[hidden email]> wrote:

On Thu, 2014-06-19 at 12:13 -0700, Daz DeBoer wrote:
[…]
Yes, we're using the term 'native' as a not very good descriptor for the
Gradle support for building applications in C, C++, Assembler, Objective-C,
Objective-C++ and Windows Resources. Unfortunately, we haven't come up with
a better term to describe this set of functionality
[…]

It all depends if the same infrastructure covers just them or all
languages resulting in native code!

Can you elaborate a little on this? Is it the way the source code is built
into a binary that is different, or the type of output that is created, or
both? Where does Assembler fall into this mix?

Sorry, but… it depends.

So for example, with Chapel you always try to compile all the source
with a single compile command generating the executable directly without
generating any intermediate "semi-compiled" files.  D is also compiled
in this way by preference. However D can also be compiled in the classic
C++ approach of compile each source file into an object file and then
link all the objects together to create the executable.

We should be able to deal with either of these approaches. Right now, the native plugins compile source to object files and then link them into a binary. However, we’ve tried to keep the assumptions about how stuff is built constrained to a single plugin or two. This means most of the infrastructure doesn’t care about how a particular binary is produced - only that it is. For example, the dependency management stuff doesn’t know or care whether a binary is compiled and linked as one step or two or 200 or none.

Having said that, there would be some work involved in adding support for building a binary directly from source in a single step.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: "Native Support" [was Google Test Support]

Russel Winder-3
On Sun, 2014-06-22 at 08:50 +1000, Adam Murdoch wrote:
[…]
>
> Having said that, there would be some work involved in adding support
> for building a binary directly from source in a single step.

It's the way forward, especially for languages with modules. D and
Chapel are at one extreme, Go's build mechanism are a mid-ground.

I can see more new languages going the single step source to executable
since it allows for global optimizations, especially of address space.
It will be interesting to see what happens in C++ after C++17 as modules
are forced into the language.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: "Native Support" [was Google Test Support]

Russel Winder-3
In reply to this post by Adam Murdoch
On Sun, 2014-06-22 at 08:39 +1000, Adam Murdoch wrote:
[…]
> One thing that is missing from the Gradle story at the moment is
> dependency management that works across all these domains. This is
> something we’re working on at the moment.

And then there is dynamic linking to libraries on the platform as well
as the idea of downloading dependent artefacts. If a build system forces
download and use of a library that is already resident via the platform
packaging, then it will not be a viable build framework for that
platform.

> For Gradle to be a realistic option for teams that develop native
> software only, we need to do something about performance - we need to
> make configuration time much faster, and we need to push parallel
> execution more. We’ve started on improving configuration time and this
> should lead to better paralysation too.

The former has been a bit of a problem for SCons, but not Waf and CMake.
SCons does all configuration at run time of each build, Waf and CMake
separate configuration from running a build. Of course this makes SCons
more resilient to unexpected changes. SCons, Waf, CMake just follow make
and use the -j flag to throw processors at a build problem. It is fairly
easy to parallelize compile actions given the data in the ADG
representing the build.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


12