Re: [cdt-dev] Antwort: [Newsletter] Re: CMake support in Eclipse CDT

[Roland Schulz <roland@xxxxxxx>]

On Mon, Dec 7, 2015 at 4:09 PM, Martin Weber <fifteenknots505@xxxxxxxxx> wrote:

Am Montag, 7. Dezember 2015, 20:42:41 schrieb Doug Schaefer:
> On 2015-12-07, 3:23 PM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of Martin
> Weber" <cdt-dev-bounces@xxxxxxxxxxx on behalf of
> fifteenknots505@xxxxxxxxx> wrote:
>
>
> >Am Sonntag, 6. Dezember 2015, 20:25:18 schrieb Doug Schaefer:
> >

> >> On 2015-12-06, 8:35 AM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of Martin
> >> Weber" <cdt-dev-bounces@xxxxxxxxxxx on behalf of
> >>
> >> >> We may need to parse the CMakeLists file for other reasons, mainly
> >> >>
> >> >>
> >> >>finding
> >> >>
> >> >>
> >> >> the binaries to launch. But we¹ll deal with that when we get there.
> >> >
> >> >
> >> >Doug, which binaries to launch? Compilers and linkers? These are
> >>
> >>launched
> >>
> >> >by
> >> >the actual build tool (make, ninja, etc).
> >>
> >>
> >> No I mean the build output. The things we¹re going to launch at launch
> >> time for run, debug, etc. Mainly all the add_executable()¹s.
> >
> >
> >Ah, I see. Build artifacts.
> >But CDT already finds these, regardless of the values entered in the
> >Settings|
> >Build Artifact tab; the executables show up in a Binaries folder in the
> >project explorer (at least as long your to-level source folder is the
> >project
> >folder). Tested with the cmake-plugin I mentioned earlier.
>
>
> It’s not quite that simple. I would want to present the executables added
> by “add_executable” in the launch bar. The launch delegate would then find
> the right version of that executable in the build output folder that
> matches the target and mode.
>
> The CDT will list each binary but doesn’t link the concept that a release
> and a debug version of a Mac and a Raspberry Pi version of the binary are
> actually the same binary just built with a different build configurations.
>
> And they need to be added to the launch bar before a build happens and the
> binaries get created. We only know they exist at that point by looking at
> the CMakeLists.txt file.
>
> Complicated, but it’s what makes an IDE great ;)

AFAICT, parsing CMakeLists.txt [1] will be an ever ongoing maintenance effort.
The language evolves constantly. Not to mention their POLICY directive, which
seems to sometimes change parsing rules.

And parsing isn't enough. You would have to interpret it. If the add_executable isn't inside a branch or a loop, and doesn't contain variables it might still be easy. But if not, than you would need to implement a full cmake language interpreter to get the correct result. Just 2 examples from our cmake file:

foreach(PROG ${CONTRIB_PROGRAMS})

        add_executable(${PROG} ${PROG}.c ${NGMX_COMMON_SOURCE})

endforeach(PROG)

function (gmx_build_unit_test NAME EXENAME)

    if (GMX_BUILD_UNITTESTS AND BUILD_TESTING)

        add_executable(${EXENAME} ${UNITTEST_TARGET_OPTIONS} ${ARGN} ${TESTUTILS_DIR}/unittest_main.cpp)

....

I think the only way to get the target names for all cmake projects (including the complex ones) is to parse cmake output files not the CMakeLists.txt. 

So either CDT should read the output of one of the existing targets (e.g. Codeblocks - that's what Clion/qtcreator do) or if that's not possible, it should add a new generator to cmake.

Roland

Martin

[1] man cmake-language(7), or https://cmake.org/cmake/help/v3.0/manual/cmake-language.7.html

--
Cd wrttn wtht vwls s mch trsr.


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

--

ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309