For a large company (700+ developers) with a very big C/C++ codebase we are looking at the possibility to e.g. use Gradle or Ivy for dependency management (and if possible build automation). The current setup is one monolithic codebase which – in some way – contains logical components. Building is done via many complex Make files.
Obviously the above described situation leads to many problems/limitations we want to solve by a) Modularizing the codebase in many (physical) components; in other words separate modules/subprojects b) Have proper dependency management in place
This way the modules can be built separately and being published to an enterprise repository (for being used by other modules).
Our first objective is the have dependency management.
One approach – which is used by other C/C++ projects – is to use Ivy to define the dependencies and then have an Ant script to resolve the dependencies. The dependencies are zip artifacts containing header and object files. The Ant script would also unpack these zips to a temporary folder to which we can link to from Make files.
With my own Groovy/Grails background I also dived into the possibility to use Gradle. a) Gradle syntax (DSL) is much nicer than Ivy XML b) Gradle supports complete build environment in which we could also easily define custom tasks etc. c) Gradle has an experimental C/C++ plugin
I looked into the current state of the C/C++ plugin and as advertised it’s indeed in early stages. As I can transitive dependency management is not yet implemented and also during publish ivy.xml are not being published.
My first questions:
- What are the plans for C/C++ plugin. Is there any roadmap available, or is this just best effort if developer working on it has time? 2) This leads also to the question if Gradle has some higher plan to be a programming language agnostic build tool?
The current status of the C/C++ plugin does not make it useable at the moment for us I think. However we could still benefit of using Gradle for dependency management and publishing of artifacts (building would be done by Make files in this case).
As Gradle is being told to be well suited for an existing Ivy infrastructure I started looking to use Gradle for the dependency management part, but I could not find any Ivy related resolve/publish tasks. Is this true?
- What I wonder is can we use a Gradle dependency {} block with our dependencies and call a task to resolve the dependencies? (note that we are not applying java plugin) We also would need a tree/list of resolved dependencies to kick off a task to unpack the archives. Do you think the above would feasible with Gradle?
Regards, Marcel
- Our C/C++ plugin is work in progress, and is typically driven by open source or client demands. You can contact me offline if you are interested in moving this forward in partnership with Gradleware.
2)Yes. Gradle has successfully been used as a “meta” build tool at large organizations. We are working on improving ivy publication, please see the 1.3 release notes, and there should be further improvements in 1.4.
3)Yes. We have clients that use Gradle’s dependency manager/repository publisher APIs wrapping around make, msbuild etc.
Regards, Peter Walker COO Gradleware Inc. peter.walker@gradleware.com http://www.gradleware.com/team#peter-walker http://www.linkedin.com/in/peterbwalker Phone: 914 418 4010
Hi Peter, Thanks for replying, much appreciated.
-
Yes I will discuss this internally as an option.
-
I read about the Ivy publish plugin and generating Ivy files. However this seems (but probably isn’t) for Java environments which have compile, testCompile etc. dependencies.
In my situation these configurations are not available as they become available via Java plugin, which I do not apply as it’s not a Java project. How would I define dependencies and resolve them in such a project? I cannot find any targets related to resolving… An example would help me a lot
- Are you aware of existing documentation/samples wrapping the manager/repository publisher APIs around make (or any other build tool)? This would be very helpful.
For 2), please look at our new ivy publication features that we started incubating in 1.3. http://www.gradle.org/docs/current/release-notes#new-ivy-publishing-mechanism
- I’ve seen a few ope nsource gradle plugins wrap msbuild, xcodebuild etc, but as of now I couldn’t find one that integrates with gradle configurations. Maybe other forum posters are aware of some. I can confirm that this approach has been successfully used within companies.
Thanks Peter,
Publishing I understand, It’s now mainly how to resolve dependencies in a non-Java project.
E.g. I have:
repositories {
ivy {
url “some url”
} }
configurations {
compile }
dependencies {
compile “mycomp:mod1:2.6”
compile “mycomp:mod2:3.0” }
How would I resolve and download these dependencies from the configured Ivy repository? This means including transitive dependencies as stated in the Ivy files of these modules itself. So basically I need to download the archives (zip files). Next step would to have a list/tree of these deps to unpack them in a custom task.
Thanks, Marcel
What you have listed here should actually work and give you zip files in the gradle cache. The next step is to programmatically unpack them into a location, and then feed that location the tasks that you want to execute. I think this forum posting covers the basics. http://forums.gradle.org/gradle/topics/unzipping_dependencies_but_only_when_they_change
OK I just found something similar here http://forums.gradle.org/gradle/topics/what_is_the_best_practice_for_managing_javascript_libraries_such_as_jquery
If I understand correclt I have to create a custom task for the downloading. I had the impression there was a general task available which just call (at least for the downloading part). But with this information I can continue!
Thanks again, Marcel
PS: I’m still stumbling against retrieving a list of the resolved deps, but I made a separate question for that as it’s more generic: http://forums.gradle.org/gradle/topics/how_to_retrieve_a_list_of_actual_dependencies_including_transitive_deps