Hi, I recently got to work on a multi platform make based build, that involves a lot of C, some C++, Java and Javascript/HTML. The current system is somewhat interesting and needs some work to become more maintainable. Having successfully converted a maven java build to gradle in the past I started investigating using gradle for this job (it would make a number of things I now see a lot easier). So I was wondering what the current intended direction is of the native support.
Will multi platform builds and artifacts be supported ? (Something like the maven NAR plugin http://duns.github.com/maven-nar-plugin/) Some observations/feedback/questions after playing around with the cpp-lib/cpp-exe plugins: * It would be cool to a DSL to configure the toolchain to use. As it seems now I need to write java/groovy to support a new compiler (gcc/microsoft compilers/aix compilers) and use gradle internal classes. Configuring the toolchain via DSL might also make it easier to use some tools that use wrappers around the compiler, sometimes combined with extra options). Having the option to specify a hard path to the compiler would also be nice, I somewhat dislike relying on path lookups (paranoia :) ). * Is it possible to have a header files only dependency ? I seemed unable to turn off the attempt to download a shared object or vice versa shared object only dependencies. * I would really like a way to specify a dependency that would result in -L<somedir> and some -l<sublib1> -l<sublib2> options for the compiler, I can somewhat work around this by specifying arguments for the compiler, but it would be nice if this was possible out of the box. (this might make my migration path easier, I now have a number of do-everything builds that result in more libraries) * Will it be possible to include more shared/objects/static libraries in a dependency? I tried to include boost for its test framework with a simplistic 'boost-all' approach, e.g. header files and multiple shared objects, but got hung up on the single shared object restriction. * Will it be possible to use a more standard approach for library generation e.g. libfoo.so so you can build libraries that can be linked using -L<dir> -lfoo from other tools? * The current convention for shared object names makes it also hard to repackage some third party packages that set the shared object name soname field in the library/executable. This becomes problematic when trying to run the generated executable e.g. running a testcase compiled with boost test will try to lookup libboost_unit_test_framework.so and not the shared object name in the repository. * What is the plan for compile dependencies ? Manual? Or automatic with a gcc -MM or makedepend phase that configures dependencies (of some gradle internal mechanism)? Then build in the more conventional way .c -> .o -> .a/.so ? * Will static libraries be supported ? * Will gradle transparently deal with setting LD_LIBRARY_PATH on assorted unixes (or PATH on windows for DLL's) for running for instance test executables generated with a 'compileTest' target ? My apologies for so many questions ;) Cheers, Ric Lexmark International B.V., Gooimeer 12, 1411 DE Naarden, The Netherlands
