Andrey Chernyshev wrote: > 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.
I don't see a great advantage to asking people to learn 'cpptask' rather than 'make'. I would suggest that many more C programmers are familiar with 'make' already, so we are not asking them to learn something new. However, the Ant cpptask wrappers the same platform compiler, so the complexity in terms of options etc. is equivalent. The resource dependency checking performed by Ant and make are both done 'behind the scenes' anyway. Was there some other part of Ant and make that you were thinking about? > - 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. You are right, there is no C development environment shipped with Windows by default. I doubt we can fix that very easily :-) Everyone will need to install a C development environment to use cpptask too. > Another issue is that nmake > that comes with MSVC and gmake are not compatible with each other. Agreed. One of the many platform-specific areas we deal with everyday. At development time the differences include code and resource compilers, packaging and so on; at runtime the differences include resource management, OS APIs, etc. I see that in HARMONY-16 you have used break-out XML files (jaaswin.xml and jaasnix.xml) to deal with the build-time differences. That's fine. Some level of the tooling will have to bridge the differences. > - Overall, ant possibly better suites the portability needs, at least > between Windows and Linux There is a distinction to be drawn between the portability of the 'product' (i.e. the VM, class libaries, tools, etc.) that we are building, and the portability of the toolsuite that is used to build it. I'm not convinced of the need to make the development toolset portable across all platforms. I'd rather enable people to choose their development tooling within the broadest set of resources that we are prepared to support consistently. So if people want to use command-line tools (emacs, make), or IDEs (Eclipse CDT or VisualSudio) then they should be free to make that choice. > 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. I think the discussion is simply at what point the Ant script does a platform-specific <exec>. When using 'make' the script calls-out early and uses make to manage the native code side dependencies; when using 'cpptask' the script calls-out later and uses Ant to manage the dependencies. We figured that 'make' was a more universal C build system than cpptask. > Thank you, > Andrey Chernyshev > Intel Managed Runtime Division > Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
