__FILE_NAME__ not defined in gcc < 12

[aeschbacher]

There are situations (when saving space is critical) where preferring the __FILE_NAME__ predefined macro over __FILE__ can make sense. Unfortunately the __FILE_NAME__ macro is not available before gcc 12.

With GNU Make, it would be possible to #define it using -D__FILE_NAME__ and some $< magic. I failed to find the right way of doing this with Meson build. The obvious answer would be for sure to wait until it's possible to update to gcc 12 for the project (but upgrading a cross toolchain is a bigger change).

I'm wondering if it's possible in Meson with a reasonable effort ?

[mitchgrout]

I don't think it's necessarily meson's place to provide such a macro. This could be readily resolved in your application without meson contributing at all, e.g.

/* project/config.h */
#pragma once

#if !defined(__FILE_NAME__)
  static inline const char *basename(const char *path)
  { /* return the pointer after the last / in the string */ }

  // NOTE: Technically UB to define this name, but do what you need to
  #define __FILE_NAME__ basename(__FILE__)
#endif

[eli-schwartz]

Does fmacro-prefix-map help here to chop off the leading portion of the macro expansion and replace it with ''?

[aeschbacher]

Using -fmacro-prefix-map allows to easily remove the common part of the string (e.g. ../../git/src/) , which is already a good improvement, thanks.

[aeschbacher]

I ended up with:

rel_source_dir = run_command([
    'realpath', '-m',
    '--relative-to=' + meson.project_build_root(),
    meson.project_source_root()
  ],
  check: false).stdout().strip()

flags = [  '-fmacro-prefix-map=' + rel_source_dir + '/=' ]

add_project_arguments(flags, language: ['c', 'cpp'])

[mitchgrout]

As a note as of meson 1.3.0 there is fs.relative_to which should be able to provide the same behaviour your run_command. I would be cautious about using -fmacro-prefix-map as while it does reduce your end binary size, I believe it can impact how tools like gdb are able to do instruction-to-source-line mapping

[aeschbacher]

Good to know, thanks