[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Build Update
|
Answers:
1] CMake can generate any number of "build systems". The best fit in
this instance (IMO) would be to have CMake generate plain makefiles (or
"makefiles" for the system your are on: MinGW; MSYS: Cygwin). With that
out of the way, then the CMake Project Importer would create a "Standard
Makefile Project (unmanaged).
2] If the user changes the CMakefile (whether inside or outside the
project), the Makefile will detect this, rerun cmake, which then
regenerates some/all the makefiles, and the "make" takes back over and
compiles the project. This is where CDT is actually BETTER than the
other IDEs in that CDT reasonably handles the generation of the make
files without a problem since CDT is just calling "make" with the proper
arguments and piping the output back to the CDT build console. What
happens in other IDE's project files is that they get regenerated by
CMake any time a CMake file is changed. Visual Studio will ask if you
want to reload the projects. Xcode asks the same thing. In both
circumstances if you have set anything inside the IDE without going
through CMake, like compiler flags, those will be over written by
CMake's regeneration of the project files. Yep. It sucks.
Hope that helps
Mike Jackson
On 3/3/2010 11:52 AM, Treggiari, Leo wrote:
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 <mailto: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.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
