Community
Participate
Working Groups
Current support to build with cmake still is poor. Users are given just an 'Invoke CMake GUI' button that tries to start the cmake-gui tool (and that crashes). Buildscript generation often fails saying 'Build not configured correctly' without giving users any hint of the cause and not giving them means to configure the build correctly. CDT-cmake should take the user's CMakeLists.txt files as the source of truth for building, thus allowing to re-use the CMakeLists.txt files to run e.g. CI builds. In contrast, CDT managed build takes the CDT project settings as the source. CDT-cmake should support to let developers check-out a repository from SCM and have the CDT projects inside it built -- without requiring them to perform any manual steps to first generate the build-scripts and without without forcing them to configure cmake's build-script generation first. Check-out, build and start debugging is the goal here. To achieve this, cmake build support Must [M]/Should [S] allow users to specify (and persist in SCM) the following project settings: - [M] source folder; relative to project location (CDT 10.0 and prior hard-code this to project location) - [M] build output folder; relative to project location or a linked folder. The actual build output directory in the file-system will be created (as a derived eclipse resource), if non-existing. NOTE: The above two settings are not inherently tied to cmake, the MesonBuild and QtBuild might want this settings, too. - [M] Command-line options to pass to cmake for build-script generation. The existing 'Invoke CMake GUI' button only allows to change cmake cache variables, *after* cmake was run, but cache variables are not command-line options. -- Only command-line options that make sense for build-script generation will be supported. -- [M] The '-D' option. One of its uses is to tell cmake to perform cross-compilation e.g. for embedded controllers. - [M] For settings that take a file system path as the value, users must be able to specify Eclipse variables and project relative paths which get automatically expanded. (To have SCM-/team-friendly project setting files.) - [S] Settings for in-container-builds. And finally: Cmake is a cross-platform build-system generator. Concerning a CDT project being developed on different platforms/OSes, the proposed cmake support [M] must be SCM friendly, that is: It must not force users to modify project settings to build on their specific OS. Cmake4eclipse for example has a concept to specify and store cmake options that get automatically activated based on the OS eclipse is running under.
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/170519
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/170716
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/170738
Gerrit change https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/170738 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=af1b6fa2380698a3bc8cbcb185a45969bd38af31
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/171322
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/171417
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/171718
Gerrit change https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/171322 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=3a10f42019582d0b4ab3d2ead5582207d57245ce
Gerrit change https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/171417 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=ebf2d24c95600d4be9bf9653db24f983902b4a78
Gerrit change https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/171718 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=de80240232b733bab0de9ee4cc05fdf19184a97e
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/172268
Gerrit change https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/172268 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=9a70f31c4ecbbf9cf7ecdb810c74a03ff0da6798
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/172328
Gerrit change https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/172328 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=4213379279067dfe25a16bd5e22904b8c18252d2
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/173466
Created attachment 284979 [details] CMake UI 1
Created attachment 284980 [details] CMAke UI 2
(In reply to Martin Weber from comment #17) > Created attachment 284980 [details] > CMAke UI 2 Its great to have this GUI more accessible. I am not sure how this works with the launchbar and target selection options there - but I am not sure anyone is relying on that behaviour anyway, so I like how this moves it forward. Well done Martin.
FYI, in Embedded CDT the Arduino-ish toolbar is disabled by default, and I suggest you do not depend on its presence.
(In reply to Jonah Graham from comment #18) > (In reply to Martin Weber from comment #17) > > Created attachment 284980 [details] > > CMAke UI 2 > > Its great to have this GUI more accessible. > > I am not sure how this works with the launchbar and target selection options > there - but I am not sure anyone is relying on that behaviour anyway, so I Ooh, well, the launchbar. Guess I broke it; I was not aware that it is also used for *building*. And given the lack of documentation of CMakeBuildTab, it is hard to spot that the tab is related to the launchbar. For managed build, the launchbar is useless and just eating up screen-space; so I think I am not the only person who never explored it fully and removed it from the project perspective. So how could the launchbar be fixed for building with cmake? The concepts of this bug and the launchbar build differ. This bug is trying to store setting for cmake with the project in SCM, allowing to generate build-scripts and build for the build platform configured in the settings when the user selects the Build | Project menu. No manual interaction required to build the project. The launchbar in contrast seems to store the build settings in the workspace and allows to quickly switch the target for building (e.g. for different embedded controllers). This is nice, but my guess is that at least 80% of the users use native build while developing. To adopt the launbar-settings to some extend, I can imagine to append the cmake arguments pass in from a launchbar-build to the arguments stored for the project.
Hi Martin, I've been working with Renesas to integrate some custom cross compilation CMake functionality into the Renesas e2 studio/ADAS product. So it's always encouraging when I see improvements to the CDT CMake functionality. I like the direction this looks like it's going in, especially the UI mockup for the project properties page: that's not in the release yet right? I also like that you have placed some interfaces in public API for this. The integration I'm doing relies heavily on use of the Launch Bar. My Launch Target contains a number of parameters which are required to be passed to CMake as -D args. One problem I've faced with this new CDT (just picked up 10_1_0) work is how these arguments are passed to CMakeBuildConfiguration. I extend CMakeBuildConfiguration and am using the previously supported setProperty(CMakeBuildConfiguration.CMAKE_ARGUMENTS, args) approach. In CDT 10_1_0 this is now broken for me and I'll have to fix it; a consequence of referencing internal packaging. Going forward, one of my requirements is that my CMake arguments should not be handled by the new ICMakePropertiesController because they are transient properties that shouldn't be persisted. The scenario is the user changes a setting in the Launch Target (eg change the target hardware device ID) to perform their build. They would then do some debugging on that target. They then might have a different target hardware that they wish to debug on; both changes in target hardware ID should not cause a file change which would then be a SCM commit candidate. Another requirement for cross compilation is control of the CMake generator setting. IIUC in CDT 10_1_0 the choice of generator is dependent on platform; on Windows MinGW Makefile and on Linux Unix Makefile are automatically chosen. Great idea, but I require manual control of this to meet requirements of the underlying Renesas SDK. Happy to discuss any of these details with you if required. Cheers John Moule
(In reply to John Moule from comment #21) > Hi Martin, > I've been working with Renesas to integrate some custom cross compilation > CMake functionality into the Renesas e2 studio/ADAS product. So it's always > encouraging when I see improvements to the CDT CMake functionality. > > I like the direction this looks like it's going in, especially the UI mockup > for the project properties page: that's not in the release yet right? No, it is not in the release yet. I stopped working on integrating the UI stuff when I noticed the launch bar: Its not yet clear to me how the settings provided by the launch bar and the settings coming from the UI should be combined. Since I am not doing much C development ATM I have not gathered any uses cases yet. > > I also like that you have placed some interfaces in public API for this. > > The integration I'm doing relies heavily on use of the Launch Bar. My Launch > Target contains a number of parameters which are required to be passed to > CMake as -D args. One problem I've faced with this new CDT (just picked up > 10_1_0) work is how these arguments are passed to CMakeBuildConfiguration. I > extend CMakeBuildConfiguration and am using the previously supported > setProperty(CMakeBuildConfiguration.CMAKE_ARGUMENTS, args) approach. In CDT > 10_1_0 this is now broken for me and I'll have to fix it; a consequence of > referencing internal packaging. > > Going forward, one of my requirements is that my CMake arguments should not > be handled by the new ICMakePropertiesController because they are transient > properties that shouldn't be persisted. The scenario is the user changes a > setting in the Launch Target (eg change the target hardware device ID) to > perform their build. They would then do some debugging on that target. They > then might have a different target hardware that they wish to debug on; both > changes in target hardware ID should not cause a file change which would > then be a SCM commit candidate. I totally agree: Not each setting that ends up in an option on the cmake command-line should be persisted with the eclipse project. Currently; I can see the following where settings that affect the cmake command-line or environment variables should be applied: 0) Per CDT launch configuration. 1) Per machine; persisted in Eclipse workspace. For example; on windows: The location of the mingw/msys/cygwin C-compiler and other tools needed for a native build. This usually is /usr/bin on linux, but windows lacks a standardized location for this so users should be able to specify it. 2) Per project; persisted in SCM. Users of my Managed-build-based plugin for cmake-support demand at least to pass sth. like option '-DMYCmakeSymbol=DEBUG_XYZ' to cmake. 3) Per project, per host OS; persisted in SCM, auto applied depending on host OS. I personally demand this. For example, if I want to develop my eclipse project on linux, I want cmake to use the 'Posix Makefiles' or 'Ninja' generator to create the build scripts. On windows, cmake must use the 'MinGW Makefiles' generator *without* forcing me to change settings that cause an SCM change. 4) Per project, per *target* OS; persisted in SCM, auto applied based on detected *target* OS. Similar to the above, it is addressing cross-compilation, where *target OS* is the OS that will execute the binary artifacts produced by the build. For example, Eclipse runs on windows, builds happen in a container that is runinng and building for linux. And possible more. The tricky part is to combine all the above in a way that users can understand. Suggestions are welcome. > > Another requirement for cross compilation is control of the CMake generator > setting. IIUC in CDT 10_1_0 the choice of generator is dependent on > platform; on Windows MinGW Makefile and on Linux Unix Makefile are > automatically chosen. Great idea, but I require manual control of this to I would say this falls in category 4) from above. > meet requirements of the underlying Renesas SDK. > > Happy to discuss any of these details with you if required. Happy to get any uses cases to discuss! Martin
I have used Eclipse CDT for many years to build embedded projects. Unfortunately some of the libraries that I now need to import to my Eclipse workspace have complex CMake build scripts, so my only hope is to include them as CMake projects. I am really struggling to get this working. I can build them directly with CMake from the command line, but not from Eclipse. The first reason is that Eclipse under Windows seems to only be able to use generator "MinGW Makefiles" which as far as I can tell refers to an obsolete mingw32 build system. Its replacement is MSYS so I need to use generator "MSYS Makefiles", which is what I do (and works) when running CMake from the command line. So as an absolute minimum, the generator argument to the CMake command line invoked by Eclipse should be configurable. I suspect that an option also needs to be added to specify what toolchain file to use. There is an option in Window/Preferences/CC++/CMake to list toolchain files, but as far as I can tell they are not used anywhere.
