[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Antwort: [Newsletter] Re: CMake support in Eclipse CDT
|
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.
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.