Hi Adam, These are very interesting information. Your current feature list for short and soon-ish term is the most interesting for me (and for what I would like to achieve with Gradle). I would really like to help for anything on this list.
I may not be able to be much help for anything touching the dependency management... I don't quiet understand it at this point. As for the other feature, I could definitely give a hand. After using the NAR plugin, I could recommend some idea to implement some feature: - The static library could possibly be done by adding a linker layer were you could control it by feeding command line argument to the linker directly and possibly choose the compiler and linker to use independently. - The support for more compiler/easier to implement newer one could be done by having an idea of compiler/linker behavior that can be use/extend for a specific toolchain. For example, some embedded cross-compiler toolchain are using gcc with a different name (like arm-none-linux-gnueabi-gcc ). Been able to just specify the compiler behavior of gcc and changing the executable name that is use directly in the build.gradle file could definitely be really useful. - The compled variant was probably well addressed in the NAR plugin with the AOL properties (Architecture, Os and Linker). The only problem that I found with this was the lack of flexibility in order to modify them through your build script... but that could be address and changed :-) - The support for C and any other language could be added by adding some logic to configure a C, C++, ASM, D, etc environment within the gradle script. Again, the NAR plugin address this by having "high level" configuration that gets resolve into command line argument behind the scene for each native language (they support C, C++ and Fortran). It's also a good way to have cross-platform build script. I'm sorry if I do a lot of comparison with the NAR plugin, but that was my first and only great experience with a modern approach for managing native project. I'm pretty sure you have some though of your own on how to resolve and address the different features. I could be a good idea, like you say, to identify a strategy on how to implement these feature. Let me know how you want to tackle all these. Cheers, Daniel -- View this message in context: http://gradle.1045684.n5.nabble.com/Offering-Help-for-Native-Support-tp5707874p5709809.html Sent from the gradle-dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
