Language specific args for dependencies?

[ilg-ul]

I created a package which builds Google Test as a static library, and, in order to pass the build in my environment which is not tolerant to warnings, I had to use quite a lot of -Wno-* compiler options to silence the countless warnings.

My tests are built with gcc/clang/arm-none-eabi-gcc, on multiple platforms.

Due to the specifics of the toolchains, generally the options can be split into:

• common options that can be used both with C & C++
• options that can be used only with C (none in this specific case)
• options that can be used only with C++

The way I implemented this looks like:

message('Processing xPack @xpack-3rd-party/googletest...')

xpack_common_args = [
  '-Wno-padded',
  '-Wno-undef',
  '-Wno-missing-noreturn',
  '-Wno-switch-enum',
  '-Wno-switch-default',
  '-Wno-null-dereference',

  '-Wno-psabi',
]

if c_compiler.get_id() == 'gcc'
  xpack_common_args += [
    '-Wno-missing-attributes',
    '-Wno-aggregate-return',
    '-Wno-conversion',
    '-Wno-suggest-final-methods',
    '-Wno-suggest-final-types',
  ]
elif c_compiler.get_id().contains('clang')
  xpack_common_args += [
    '-Wno-c++98-compat',
    '-Wno-c++98-compat-pedantic',
    '-Wno-weak-vtables',
    '-Wno-unused-member-function',
    '-Wno-global-constructors',
    '-Wno-exit-time-destructors',
    '-Wno-covered-switch-default',
    '-Wno-used-but-marked-unused',
    '-Wno-extra-semi-stmt',
  ]
endif

xpack_c_args = [
]

xpack_cpp_args = [
  '-Wno-zero-as-null-pointer-constant',
  '-Wno-suggest-override',
  '-Wno-ctor-dtor-privacy',
]

if c_compiler.get_id() == 'gcc'
  xpack_cpp_args += [
    '-Wno-useless-cast',
    '-Wno-redundant-tags'
  ]
endif

xpack_3rd_party_google_test_static = static_library(
  'xpack_3rd_party_google_test',

  include_directories: include_directories(
    'googletest/include',
    'googletest/'
  ),
  sources: files(
    'googletest/src/gtest-all.cc',
  ),
  c_args: xpack_common_args + xpack_c_args,
  cpp_args: xpack_common_args + xpack_cpp_args,
)

In other words, I keep three arrays with common/c/cpp options, and I concatenate pairs when passing them to static_library().

So far, so good.

However, when having to create the dependency object, I noticed that I can pass only one compile_args, not two, as for the library.

I passed the common options, and stored the language specific options in global arrays, to be included explicitly by the applications depending on this library.

xpack_3rd_party_google_test_dependency = declare_dependency(
  include_directories: include_directories(
    'googletest/include',
  ),
  compile_args: xpack_common_args
)

xpack_3rd_party_google_test_dependency_c_args = xpack_c_args
xpack_3rd_party_google_test_dependency_cpp_args = xpack_cpp_args

With this, the definition of an executable looks like this:

sample_test = executable(
  'sample-test',
  include_directories: include_directories(
    '../include',
  ),
  sources: files(
    '../src/sample-test.cpp'
  ),
  c_args: xpack_3rd_party_google_test_dependency_c_args,
  cpp_args: xpack_3rd_party_google_test_dependency_cpp_args,
  dependencies: [
    # Tested library.
    xpack_3rd_party_google_test_dependency,

    # Portable dependencies.
    micro_os_plus_diag_trace_dependency,

    # Platform specific dependencies.
    platform_native_dependency,
  ],
  link_args: linker_options,
  link_with: [
    # Tested library.
    xpack_3rd_party_google_test_static,
  ]
)

In other words, the executable refers to:

• the static library,
• the dependency
• the global language specific args.

Is this how it is supposed to be?

I feel that either I missed something related to how dependencies should be defined in meson, or there is a small problem with the declare_dependency() signature.

If I did not get it right, is there a documentation page which explains how it should be done properly?

Thank you,

Liviu

[eli-schwartz]

Yeah, dependencies don't -- currently -- support language specific arguments. It is a long-term goal of @dcbaker to remove this limitation.

It's still possible to have multiple dependencies, and split each group of source files into one convenience static_library per language, and add the matching dependencies to the matching convenience libraries.

[ilg-ul]

Hmmm... This is not exactly a nice hack, and I'm not even sure it would work in this case.

Google Test is C++ only, and silencing the warnings in the library itself was not a problem, but when I had to include the gtest/gtest.h header in the main test executable, which is also C++, I got a new set of warnings, caused by the headers. I passed the C++ options via the dependency to the executable, the compiling the main file passed. Unfortunately the project has some other dependencies, both C and C++, and the C++ options passed via the dependency were applied to the C files too, and the build failed.

Thus I passed the options via global variables, and this did not affect the other dependencies.

But this is far from convenient.

FYI, for exactly the same package (as for all my packages) I also have CMake build configurations, which had no problems to handle language specific compile options. And generally require less effort to write.

[ilg-ul]

Feel free to transfer this to issues if you like, or, if you already have an open ticket for this issue, to add cross references between them.

[ilg-ul]

Any progress in implementing separate C/C++ arguments to declare_dependency()?

[dreamer-coding]

Found something in the docs: https://mesonbuild.com/Reference-manual_functions.html#signature17

[ilg-ul]

Can you be more specific?

[dcbaker]

It's on my list for 1.4, but I haven't started yet

[ilg-ul]

FYI, this is the hack I had to use in my latest project to accommodate per language options (more or less the same as explained in the initial report).

Alongside each dependency that I define, I also define two variables with the c & cpp args:

# https://mesonbuild.com/Reference-manual_functions.html#declare_dependency
micro_os_plus_micro_test_plus_dependency = declare_dependency(
  include_directories: include_directories(_local_include_directories),
  compile_args: _local_compile_args,
  sources: files(_local_sources),
  dependencies: _local_dependencies,
  link_args: _local_link_args,
  link_with: _local_link_with,
)
# meson dependencies cannot differentiate c/cpp args; pass them separately.
micro_os_plus_micro_test_plus_dependency_compile_c_args = _local_compile_c_args
micro_os_plus_micro_test_plus_dependency_compile_cpp_args = _local_compile_cpp_args

Later, when I have to include these dependencies, I manually collect these args too:

  _local_compile_c_args += platform_native_dependency_compile_c_args
  _local_compile_cpp_args += platform_native_dependency_compile_cpp_args

  _local_compile_c_args += micro_os_plus_micro_test_plus_dependency_compile_c_args
  _local_compile_cpp_args += micro_os_plus_micro_test_plus_dependency_compile_cpp_args

  _local_dependencies += [
    # Tested library.
    micro_os_plus_micro_test_plus_dependency,

    # Portable dependencies.
    micro_os_plus_diag_trace_dependency,

    # Platform specific dependencies.
    platform_native_dependency,
  ]

  # https://mesonbuild.com/Reference-manual.html#executable
  exe = executable(
    name,
    include_directories: include_directories(_local_include_directories),
    sources: files(_local_sources),
    c_args: _local_compile_definitions + _local_compile_args + _local_compile_c_args,
    cpp_args: _local_compile_definitions + _local_compile_args + _local_compile_cpp_args,
    dependencies: _local_dependencies,
    link_args: _local_link_args,
    link_with: _local_link_with,
  )

It is more or less functional, but it is far from ideal (to put it mildly). :-(

[ilg-ul]

I don't know how you plan to implement this, but I expect some possible compatibility issues.

Will you add separate properties like compile_c_args and compile_cpp_args? How about assembly? And possibly other languages? What will be the meaning of the existing compile_args in conjunction with the language specific properties? ? In my use case I expect to pass there only options common to all languages, and all language specific option go into the variables, but I don't know if this is correct.