Rework meson and use subdir() for library

[intractabilis]

Meson rightfully prohibits sub-projects to be referenced via .. or a full path. So if you place meson.build to a meta folder, you are really limited in what you can do inside your project. Meson needs this file to be in the root of the source tree. I attached a fully working template based on the template provided by the xpack extension. In contrast to the original template, it in fact compiles add.c as a shared library. It also has a few other goodies: (i) the default task is set to xPack: build Debug, so it can be launched with Ctrl+Shift+B; (ii) launch is configured to run gdb and to perform a build before starting debugging; (iii) c_cpp_properties.json is set up to work correctly in any configuration, in any subprojects of any subdirectory without configurationProvider property.

Since we discussed in another issue if configurationProvider is needed, you can turn off CMake Tools extension completely and see that IntelliSense is still working after removing configurationProvider, restarting VS Code and after resetting IntelliSense database. Shaded areas of inactive code will react correctly on switching configurations between Debug and Release.

xpack.zip

[ilg-ul]

I transferred this ticket to the template repository, which defines the location of the meson.build file.

I also added a separate ticket: xpack/vscode-xpack-extension-ts#19.

As for the location of the meson.build, my experience with meson is not great, and I have to better understand the details before considering changes.

Personally I prefer to not have the metadata/build files in the project root, and keep the focus on the source code.

As for the attached zip, I tried to use it on my Mac, but it is not portable, it failed with a missing dependency on meson, which is not present in the system path as on your Linux.

For a template to be really useful, it must be standalone and run on all platforms (Linux/macOS/Windows).

But templates are entirely open, you can create as many templates as you desire, and use them to instantiate projects with xpm init --template.

[intractabilis]

The project I attached was meant to serve as just an example of how to use Meson correctly. I thought you would use it to modify the existent Hello World template, not use it as is.

[ilg-ul]

Aha, ok.

Any special reason for removing the devDependencies to the binary xPacks?

[intractabilis]

Any special reason for removing the devDependencies to the binary xPacks?

I have no idea what you are talking about. I just tried to compose a minimum working example, I guess no reason at all. :)

[ilg-ul]

The xPack project provides a convenient way to add dependencies to specific versions of the required binary tools, such that you always build your project in the same environment, regardless of the platform you use. This is particularly useful when running unit tests on a CI server. Even more, you can define dependencies for each build configuration, such that you can, for example, build the same test with different versions of the toolchain.

The syntax of devDependencies property in package.json is inherited from npm, and you can see an example in the projects generated by the template.

The dependencies are processed by xpm install. If, for any reason, you decide to use the tools available in the system, you can skip the invocation of xpm install, or you can remove the xpacks folder.

But it is still a good idea to have the devDependencies defined by you projects, in case you want to build them on other platforms than Linux.

[intractabilis]

Ok, got it. Thank you for the explanation. I will use it.

[ilg-ul]

FYI, at the moment I have only a GCC 8 xPack, but 9 and 10 will be published soon, after I finalise clang 11 xPack.

For meson and ninja, I am generally no more than a release behind the upstream project, so I think this is reasonably up to date.

[ilg-ul]

I took a look at your suggestion to split the meson configuration and use subdir() to include the separate library definitions.

I'll try to update the template to use it, and let you know the result.

[ilg-ul]

I published a new release of the template using your suggestions.

Please test it with:

mkdir -p ~/tmp/test-hello
cd ~/tmp/test-hello
xpm init --template @xpack/hello-world-template@next --property buildGenerator=meson --property language=cpp
xpm install
xpm run test

For now the project is @next, if you confirm it is ok I'll promote it to @latest.

[ilg-ul]

@intractabilis, any chance to check if the meson code used by the new release is ok?

[intractabilis]

Sorry for a delay.

Here is the command line generated for the .cpp file:

g++ -Ihello-world.p -I. -I../.. -I../../include -I../../libs/adder/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -g -DDEBUG -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -fno-omit-frame-pointer -MD -MQ hello-world.p/src_hello-world.cpp.o -MF hello-world.p/src_hello-world.cpp.o.d -o hello-world.p/src_hello-world.cpp.o -c ../../src/hello-world.cpp

Obviously, gnu++17 didn't find its way to the command line.

[intractabilis]

However, the objective of this issue is fulfilled, gnu++17 is another problem.

[ilg-ul]

Hmmm... indeed. Since my knowledge of meson is quite poor, do you have any suggestion where to add this definition so that it'll find its way to the command line?

[intractabilis]

It should be in the project statement. I believe it also can be set in another way, but Meson developers recommend the project statement. It's in my example I attached earlier.

[ilg-ul]

Aha, so it must be passed via the project statement. I added a separate issue and fixed it.

[ilg-ul]

Fixed on 2021-06-20.