Brandon (and everyone else reading this), I fear you misunderstood something from my last message, when you said "CMake's level of Java support is a strategic risk. Eclipse isn't just a cross-platform crowd, it's a cross-platform heavily Java crowd. "
What I meant was that we need as good as possible integration between cmake and the eclipse CDT. As I am sure you are aware, the CDT is 100% C++, and has nothing to do with Java. Regarding Eclipse in a more general sense so we are all clear, I want to get one possible misconception out of the way... While the Eclipse platform was primarily written using Java, the eclipse platform should by no-means a Java IDE. Forgive me if you know about all this already... but I am sure there are other C++ folks here that are not aware of the background. Think of it this way: "How can you call Eclipse an IDE if it does not include a compiler?" In other words, how can it be an "Integrated" Development Environment, if it doesn't come with everything you need to actually use it? What the Eclipse platform really IS though, is a great platform for making IDEs. One great example of an IDE written using the Eclipse platform is the Eclipse Java IDE, which is arguably the most popular Java IDE around. Of more interest to this group though, I assume are C/C++ IDEs. Besides the Eclipse C/C++ IDE (CDT) 4.0 which I mentioned before, there are number or open source and or commercial C++ IDEs built using the Eclipse Platform including: Nokia Carbide C++ IDE Wind River Workbench LynuxWorks Luminosity QNX Momentics ACCESS Linux Platform Development Suite Mentor Graphics EDGE Developer Studio Telelog Tau Hi-tech Hi-Tide Now you might ask: why does this matter? Or Why are you telling us all this? The point I am making is that if a cmake plugin plays well with the Eclipse CDT IDE and makes C++ development easier, we get exposure to the potential userbase automatically for all those other C++ IDEs listed above as well automatically, as they are built on top of the Eclipse platform. So, to make a long story short, don't worry about the java crowd. This is all about C/C++ :) Cheers, Ding. >>> "Brandon Van Every" <[EMAIL PROTECTED]> 31/07/2007 2:22:56 a.m. >>> On 7/30/07, Andy Dingfelder <[EMAIL PROTECTED]> wrote: > > Personally, my motivation is that I want to use Eclipse on Linux to > develop both java and c++ apps, and want them to run on mac, Linux and > PC. I have seen multiple discussions in a variety of places that talk > about how to do this, some with better luck than others. I see cmake as > a natural fit for Eclipse as (IMHO) Eclipse is perhaps the most widely > used *multi-platform* environment out there, running on basically any OS > that java runs on, and everyone here knows the strengths of cmake, so I > don't need to expand upon that. CMake's level of Java support is a strategic risk. Eclipse isn't just a cross-platform crowd, it's a cross-platform heavily Java crowd. So if CMake's Java support is irritating to work with, that could put off Eclipse tool developers, whatever CMake's C/C++ merits are. On the other hand, getting one's feet wet with Eclipse and Java would be a good way to drive the improvement of CMake's Java support. I would just anticipate a lot of bumps, and invitations to substantial work. I do think that light would ultimately be seen at the end of the tunnel, however. Code::Blocks doesn't have any Java encumbrance, it's a C/C++ developer crowd. Of course it doesn't have nearly the number of users as Eclipse, nor the commercial acceptance and clout, so that's a strategic risk. I think someone would have to either be a Code::Blocks diehard and really want to get it done, or else it would have to be relatively easy to do. Otherwise, nobody would bother. Another risk with Code::Blocks is their release policy is immature. They might have great stuff, but they can't seem to manage to put an official binary distribution out there. Instead one does this daily snapshot download dance, grabbing 3 different files. It suggests to me that their architecture could be in flux, which could make CMake support a moving target. Chasing a handful of devs that don't really value release maturity or commercial stability might be no fun at all. But I don't actually know their culture or the relative stability of their code, so I won't pass judgment. Be sure to research it before diving in though. The Eclipse community is very mature as far as their release policies. Cheers, Brandon Van Every _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. SirTrack http://www.sirtrack.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake