Support native objc Gradle building about j2objc-gradle

[brunobowden]

This is very interesting Advay. We should discuss this in person when we
meet up.

On Tue, May 19, 2015 at 10:48 PM Advay Mengle [email protected]
wrote:

I don't use Xcode directly**, instead I prefer to use the Gradle wrapper
for Xcode clang toolchain.
See https://docs.gradle.org/current/userguide/nativeBinaries.html

All functionality (that I need at least) of both j2objcc and Xcode pods
can be done in Gradle directly. So I'm basically using the j2objcTranslate
functionality, and then doing the rest in gradle (without j2objcTest or
xcode pods). My current setup is at:
https://gist.github.com/advayDev1/636f34fa80164645e205
This sets up normal Gradle tasks for building my objc libraries, building
test executables, and running tests.

I think folks might want to use Xcode pods or Gradle builds, and the core
plugin probably should not enforce either. Neither actually are very
coupled to j2objc, which is purely translation. I propose we have a tools/
subdirectory or similar that supports pods and gradle native builds, so
users can choose what they want.

** For many reasons, most importantly:

• Xcode doesn't handle non-flat source directories very well.
• I prefer to use one build toolchain (and one IDE when needed,
  IDEA/Android Studio) without denormalization/duplication of configuration.
• Using a single Gradle build ensures a single presubmit/build command
  builds and tests all platforms and all flavors of my projects.

—
Reply to this email directly or view it on GitHub
https://github.com/brunobowden/j2objc-gradle/issues/76.

[advayDev1]

@brunobowden Yep will do.

@confile pointed out that perhaps we should be directly using pods on another issue, without the raw copy. This issue addresses yet another alternative. Maybe we can continue the discussion here.

[advayDev1]

btw, i upgraded one of my projects to gradle 2.4 today and using native
clang compiler is way faster/more parallel (and gets incremental build
correct) than exec-ing j2objcc (for the j2objcCompile task)...

On Wed, May 20, 2015 at 3:31 PM Bruno Bowden [email protected]
wrote:

This is very interesting Advay. We should discuss this in person when we
meet up.

On Tue, May 19, 2015 at 10:48 PM Advay Mengle [email protected]
wrote:

I don't use Xcode directly**, instead I prefer to use the Gradle wrapper
for Xcode clang toolchain.
See https://docs.gradle.org/current/userguide/nativeBinaries.html

All functionality (that I need at least) of both j2objcc and Xcode pods
can be done in Gradle directly. So I'm basically using the
j2objcTranslate
functionality, and then doing the rest in gradle (without j2objcTest or
xcode pods). My current setup is at:
https://gist.github.com/advayDev1/636f34fa80164645e205
This sets up normal Gradle tasks for building my objc libraries, building
test executables, and running tests.

I think folks might want to use Xcode pods or Gradle builds, and the core
plugin probably should not enforce either. Neither actually are very
coupled to j2objc, which is purely translation. I propose we have a
tools/
subdirectory or similar that supports pods and gradle native builds, so
users can choose what they want.

** For many reasons, most importantly:

• Xcode doesn't handle non-flat source directories very well.
• I prefer to use one build toolchain (and one IDE when needed,
  IDEA/Android Studio) without denormalization/duplication of
  configuration.
• Using a single Gradle build ensures a single presubmit/build command
  builds and tests all platforms and all flavors of my projects.

—
Reply to this email directly or view it on GitHub
https://github.com/brunobowden/j2objc-gradle/issues/76.

—
Reply to this email directly or view it on GitHub
https://github.com/brunobowden/j2objc-gradle/issues/76#issuecomment-104062500
.

[brunobowden]

Can you make this an option? Then we can consider switching it to the
default over time.

On Sun, May 31, 2015 at 5:12 PM Advay Mengle [email protected]
wrote:

btw, i upgraded one of my projects to gradle 2.4 today and using native
clang compiler is way faster/more parallel (and gets incremental build
correct) than exec-ing j2objcc (for the j2objcCompile task)...

On Wed, May 20, 2015 at 3:31 PM Bruno Bowden [email protected]
wrote:

This is very interesting Advay. We should discuss this in person when we
meet up.

On Tue, May 19, 2015 at 10:48 PM Advay Mengle [email protected]
wrote:

I don't use Xcode directly**, instead I prefer to use the Gradle
wrapper
for Xcode clang toolchain.
See https://docs.gradle.org/current/userguide/nativeBinaries.html

All functionality (that I need at least) of both j2objcc and Xcode pods
can be done in Gradle directly. So I'm basically using the
j2objcTranslate
functionality, and then doing the rest in gradle (without j2objcTest or
xcode pods). My current setup is at:
https://gist.github.com/advayDev1/636f34fa80164645e205
This sets up normal Gradle tasks for building my objc libraries,
building
test executables, and running tests.

I think folks might want to use Xcode pods or Gradle builds, and the
core
plugin probably should not enforce either. Neither actually are very
coupled to j2objc, which is purely translation. I propose we have a
tools/
subdirectory or similar that supports pods and gradle native builds, so
users can choose what they want.

** For many reasons, most importantly:

• Xcode doesn't handle non-flat source directories very well.
• I prefer to use one build toolchain (and one IDE when needed,
  IDEA/Android Studio) without denormalization/duplication of
  configuration.
• Using a single Gradle build ensures a single presubmit/build command
  builds and tests all platforms and all flavors of my projects.

—
Reply to this email directly or view it on GitHub
https://github.com/brunobowden/j2objc-gradle/issues/76.

—
Reply to this email directly or view it on GitHub
<
https://github.com/brunobowden/j2objc-gradle/issues/76#issuecomment-104062500

.

—
Reply to this email directly or view it on GitHub
https://github.com/brunobowden/j2objc-gradle/issues/76#issuecomment-107261781
.

[advayDev1]

I'll document some stuff for our Tuesday get together and we can decide
whether it is the way to go. SG?

On Sun, May 31, 2015, 5:17 PM Bruno Bowden [email protected] wrote:

Can you make this an option? Then we can consider switching it to the
default over time.

On Sun, May 31, 2015 at 5:12 PM Advay Mengle [email protected]
wrote:

btw, i upgraded one of my projects to gradle 2.4 today and using native
clang compiler is way faster/more parallel (and gets incremental build
correct) than exec-ing j2objcc (for the j2objcCompile task)...

On Wed, May 20, 2015 at 3:31 PM Bruno Bowden [email protected]
wrote:

This is very interesting Advay. We should discuss this in person when
we
meet up.

On Tue, May 19, 2015 at 10:48 PM Advay Mengle <
[email protected]>
wrote:

I don't use Xcode directly**, instead I prefer to use the Gradle
wrapper
for Xcode clang toolchain.
See https://docs.gradle.org/current/userguide/nativeBinaries.html

All functionality (that I need at least) of both j2objcc and Xcode
pods
can be done in Gradle directly. So I'm basically using the
j2objcTranslate
functionality, and then doing the rest in gradle (without j2objcTest
or
xcode pods). My current setup is at:
https://gist.github.com/advayDev1/636f34fa80164645e205
This sets up normal Gradle tasks for building my objc libraries,
building
test executables, and running tests.

I think folks might want to use Xcode pods or Gradle builds, and the
core
plugin probably should not enforce either. Neither actually are very
coupled to j2objc, which is purely translation. I propose we have a
tools/
subdirectory or similar that supports pods and gradle native builds,
so
users can choose what they want.

** For many reasons, most importantly:

• Xcode doesn't handle non-flat source directories very well.
• I prefer to use one build toolchain (and one IDE when needed,
  IDEA/Android Studio) without denormalization/duplication of
  configuration.
• Using a single Gradle build ensures a single presubmit/build
  command
  builds and tests all platforms and all flavors of my projects.

—
Reply to this email directly or view it on GitHub
https://github.com/brunobowden/j2objc-gradle/issues/76.

—
Reply to this email directly or view it on GitHub
<

https://github.com/brunobowden/j2objc-gradle/issues/76#issuecomment-104062500

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/brunobowden/j2objc-gradle/issues/76#issuecomment-107261781

.

—
Reply to this email directly or view it on GitHub
https://github.com/brunobowden/j2objc-gradle/issues/76#issuecomment-107261916
.

[confile]

@advayDev1 Not sure what you are talking about but I will have a look at your documentation.

[advayDev1]

For now take a look at the gist linked to from the first post. It is close
to what I have running internally and should be self explanatory if you
also read the gradle native build link in the same post.

Re my last comment: In gradle 2.4 they made native compiles run in parallel
according to the number of cores you have.

On Sun, May 31, 2015, 5:35 PM Michael Gorski [email protected]
wrote:

@advayDev1 https://github.com/advayDev1 Not sure what you are talking
about but I will have a look at your documentation.

—
Reply to this email directly or view it on GitHub
https://github.com/brunobowden/j2objc-gradle/issues/76#issuecomment-107269859
.