On 11/15/05, Tim Ellison <[EMAIL PROTECTED]> wrote: > In the end we decided to go with a 'conventional' native code tool set > for the native source, and 'conventional' Java code tools for the Java > source. People just felt more comfortable with that. > > Do you think we are missing out on something ;-) ?
Well, I can see a few potential issues with such "mixed" approach: - In order to contribute, people would have to learn both building technologies - Ant and make, someone may give up. - Having make in addition to ant will introduce additional dependencies for the build. While make is available on Unix systems, it is not available on Windows by default, one would have to install it as a part of cygwin, MSVC or whatever. Another issue is that nmake that comes with MSVC and gmake are not compatible with each other. - Overall, ant possibly better suites the portability needs, at least between Windows and Linux As an example, I can suggest to look at Intel's contribution of the security package at http://issues.apache.org/jira/browse/HARMONY-16. Though the experts may say the example isn't ideal (the native part of security is really simple such that the build doesn't even utilize ant cpptask), it still may serve as illustration of the alternative approach, e.g. building a product using a single language. Thank you, Andrey Chernyshev Intel Managed Runtime Division
