search

gradle / gradle-native

The home of Gradle's support for natively compiled languages
https://blog.gradle.org/introducing-the-new-cpp-plugins
Apache License 2.0
92 stars 8 forks source link

Objective-C language support #163

Open lacasseio opened 6 years ago

lacasseio commented 6 years ago

Allow executables and libraries to be built from Objective-C, and to be consumed from the same build and other builds in the same composite, and via a Maven repository.

Allow an Objective-C component to use a C or C++ library. Allow joint compilation so that a component may be implemented using a mix of Objective-C, C and C++.

Allow unit tests to be implemented in Objective-C and compiled and executed. Allow import into an IDE. Multi-variant support, as for C++.

Estimate: 5 days

acecilia commented 4 years ago

Is there any place where I can get more information about the progress of this feature? Thanks!

lacasseio commented 4 years ago

Unfortunately, there isn't much progress on this front. The old software model plugins are still the best place for an out-of-the-box solution. We could focus on improving ad-hoc instance of the compile tasks to allow you to still compose simple project from those basic tasks. Or we could open the discussion around adding support for the other native language.

Could you tell us what are the is your use case for the Obj-C language? Are you building application or libraries? Are you cross-compiling or building applications/libraries for iOS or macOS? Are you mixing native language like C/C++ inside the Obj-C component or the opposite?

acecilia commented 4 years ago

I am part of an organisation with several obj-c libraries, but no applications. This libraries are used only for iOS development at the moment. The libraries only contain obj-c code.

The old software model plugins are still the best place for an out-of-the-box solution.

I can not find much information online about how to build an obj-c library with gradle, could you provide a link to the old software model plugins, or maybe an example project? Also, in case I manage to use the mentioned software models to build obj-c libraries, will they support using the cache?

Let me elaborate a bit more about this:

At the moment the swift ecosystem is built around source dependencies. Support for prebuilt binaries is there (using carthage), but the existing solutions are not mature yet. In addition, the main build system xcodebuild has a very limited support for caching the build artifacts. In practise, this means that if you want to create a modularise codebase that you can reuse for building apps, sooner than later you will find the problem of long build and test times.

At this point, there are some alternatives build systems that try to tackle this problem: buck and bazel. The main issues that I think they have are:

Overall: you may be able to make buck and bazel work for your organisation, but it will require a considerable amount of resources during setup, and you will need to make compromises (for example, you will need to reorganise your code in a monorepo setup).

The fact that gradle is adding support for swift allows developers to benefit from a build tool that makes usage of aggressive caching, and at the same time provides all benefits that come from using gradle, such as source dependencies, build cache, composite builds, finer grained parallel execution, build scans, and more. But also consider that swift is a very young language, and the companies that could benefit the most from using gradle are the ones that have a considerable codebase: this means that they will probably have big amounts of obj-c code as well.

In my case, in order to be able to use gradle for my swift apps and libraries, I will first need to find a way of depending on and consuming my obj-c libraries.

lacasseio commented 4 years ago

I see what you are asking and you could very well help contribute the work in Gradle. Given what you are saying, there are 2 aspect that needs to be improved: 1) Objective-C library support and 2) support to cross-compilation to iOS (ARM). For both of those, we should still start with a demonstration through a sample that would allow us to see where the rough edges are. Then we can look what we can work together as part of contribution.

I created issue https://github.com/gradle/gradle-native/issues/1051 for writing a Objective-C library sample. We can refer to https://github.com/gradle/gradle-native/issues/487 for the cross-compilation sample.