RE: [cdt-dev] Build Update

["Treggiari, Leo" <leo.treggiari@xxxxxxxxx>]

I’m not familiar with CMake, and so maybe my questions won’t make any sense.  Given the description below, would it make sense to provide an “Import CMake project” menu item that does all of work while Eclipse is running?  Assuming this could be implemented, then my questions are:

 

1.       What build system does this project use?  Does CMake generate a make file and this would use the “standard”, “unmanaged” build system – i.e. CDT invokes the make file created by CMake?

2.       If the user later changes the CMake file (I’m assuming outside of Eclipse) how do those updates get reflected in the CDT project?

 

I have another general comment.  As a tool-chain provider, I would like to provide a description of my tool-chain (e.g. the MBS schema) that works with as many builders as possible.  I don’t think that there is much that is make specific in the current schema, but if there is, that’s OK as long as we specify which parts of the schema are “common” and which parts are used by a specific builder.  To look at it another way, there are 2 ways to deal with the build file:  The user manages it (from CDT’s perspective it is “unmanaged”), or CDT manages it (MBS).  It happens that the current MBS implementation creates only make files but I don’t see any reason why it could not generate build files for other builders as well (SMOP).

 

Leo

 

---

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Wednesday, March 03, 2010 8:09 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Build Update

 

On Wed, Mar 3, 2010 at 8:56 AM, Michael Jackson <mike.jackson@xxxxxxxxxxxxxx> wrote:

On 3/2/2010 10:48 PM, Doug Schaefer wrote:

BTW, I find CMake's CDT project generator weird. We've always claimed the .cproject format and contents to be internal interfaces which could change at any time. And you have a chicken/egg situation. If you are using the CDT with your project, you'll already have these files created. At any rate, I'd prefer to use CMake as a Makefile generator only.

Probably using CMake in that capacity is the best way to implement it. That way I do not have to actually have CDT running if I want to do a quick build from the command line (like if I was SSH'ed into my OS X box).

 Typically one would use CMake to generate the IDE project files. Then "Double click" the project file in order to Launch the IDE and load the project. CDT does not work this way at all and you end up with like you stated. Do I launch CDT first then do CMake or CMake then Eclipse? I think the general consensus is that when starting from a clean project directory (which MUST be located in the workspace), you would create the build directory, use CMake to generate the CDT files, switch to CDT, then use "Import Project" to import the project into your workspace. Not better, not worse, just different. QtCreator is not much better. It leaves project files sprinkled all throughout my source directories which becomes messy when something like CVS/SVN/Git is used.

 

That's a great point and another major issue, especially for people coming from Visual Studio, and something we've talked about in the past. We really need a project system that isn't forced to map to the file system, in particular make a .project file work like other IDEs and list the resources. Then the CMake strategy would make sense. There's some interesting work going on in e4 right now by the folk at SAP about enabling RESTful resources that might be applicable here.