Few improvements for IDE(QTC) integration

[jeandet]

Hi,

I'm writing a plugin for Qt Creator, here are few things that we could improve to make integration better/easier:

1. querying version speed, meson --version takes quite a lot of time. This makes meson setup UI quite unresponsive. Here are some measurement on my laptop:

   
   time meson --version                                                                                                                 
   0.54.0
   meson --version  0.29s user 0.04s system 99% cpu 0.330 total
   ===================================================
   time python -c 'import sys;import os;print("hello")'                                                           
   hello
   python -c 'import sys;import os;print("hello")'  0.02s user 0.00s system 96% cpu 0.021 total
   ===================================================
   time ninja --version                                                               
   1.10.0
   ninja --version  0.00s user 0.00s system 84% cpu 0.001 total
   ===================================================
   time cmake --version              
   cmake version 3.17.0

CMake suite maintained and supported by Kitware (kitware.com/cmake). cmake --version 0.00s user 0.00s system 96% cpu 0.006 total

Maybe this could be improved by implementing a kind of short path for --version argument.

2. meson compile command might accept a target as argument, like cmake it could be something like ```meson compile -C build_dir --target any_target``` 

3. intro-buildoptions.json seems to lack default values, this makes hard/impossible to reset a single build option from Qt Creator.

4. forcing Qt kit, I didn't investigate this yet but in Qt creator you have to deal with 'kits'. A kit is mainly a build environment where you force a Qt SDK, C++ compiler, C compiler, debugger, optionally a CMake exe and now optionally a Meson exe. So as I remember in Meson, Qt SDK can be found with pkg-config, qmake and cmake and this can be forced in meson.build files. This makes quite inconvenient to force Qt SDK from Qt Creator.

5. importing build folders, Qt creator has an optional feature, while creating a new project it tries to import existing build folders. This is done by implementing some code which search for existing folders with specific names (like build-${project-name}-${debug|release|...}) and then trying to match them with existing kits by analyzing them. Matching kits implies to have easy access to which compiler and Qt SDK is used for a given build. Maybe this would make sens to add another introspection file with the list of all used binaries, a kind of find_program log?

That's all for now, 2. and 3. are more important I would say, 2. would allow to integrate Meson without having to deal with Ninja or any other backend. 

[mensinda]

For 3: You can use meson introspect --buildoptions /path/to/meson.build to get all build options set to their default values. This works without a build directory.

For 5: So you essentially want a dump of all compilers + all external programs found by meson?

[jeandet]

@mensinda, thx for meson introspect --buildoptions /path/to/meson.build that does the job, I would anyway advocate for adding a default_value field in intro-buildoptions this avoids a meson call and doesn't costs much. That would be much better if the only source of information for this plugin could be meson-info folder, that makes the code and the design more comprehensible.

For 5. in fact this was an idea, I didn't think more about this but basically yes dumping all compilers and external programs could be the solution, I don't know if others IDEs or tools might also find some uses of this? Any other idea is welcome.

[mensinda]

Normally there wouldn't be a problem with adding a new key to the introspection format, however, in this case, quite a bit of refactoring would be required. This is because the default values aren't actually stored anywhere in meson. See UserOption and derived classes in coredata.py.

Also, with meson introspect --buildoptions /path/to/meson.build you can let the user see and change build options before the project is configured, so I would recommend implementing support for this anyway (feel free to have a look at my KDevelop meson plugin).

[jeandet]

@jpakkane, @textshell , any opinion on item 2? I believe that meson should offer an interface which decouple IDE/client from backend, since it has most backend knowledge that doesn't make any sense to duplicate this in IDE. CMake does this, that the only part I jealous in QTC about CMake plugin in QTC :).

[jpakkane]

Mensinda's comment above seems to indicate that you can get this information already. Is that not the case? Or is there something missing?

[jeandet]

@jpakkane, I was asking about item 2 issue in description:

meson compile command might accept a target as argument, like cmake it could be something like meson compile -C build_dir --target any_target

I got 0 feedback on this specific point.

[jpakkane]

That would be equal to adding new command line options for meson compile to specify which target to build? Sure we can add that, the interesting problem there being how should the targets be specified? With the unique id?

[jeandet]

The safer would be unique id, but if we want to also make this command usable by humans then ninja target names would be better. The issue is that I've no idea if this could work with other backends. Do they use same target names? If one day we add a new backend will that break? I might have missed other pitfalls.

[mensinda]

If I remember correctly, the ninja names can also change depending on what layout type is used (flat vs. mirror). So, the only stable strings are the meson IDs, as far as I can tell. And if you have to deal with backend-specific IDs you might as well call ninja or MSBuild directly IMHO.

Alternatively, we could also make meson accept both options...

[jpakkane]

Or we could have a command line argument like --build-only-target-with-id that takes the ID as an argument. That gets the IDE integration going and we can add a human readable version of the argument later.

[jeandet]

Perfect! thx for your answers.

[TheQwertiest]

Possibly related feature request: https://github.com/mesonbuild/meson/issues/6740