"always broken" str.format() warning vs getting filenames from 'file'

[anarazel]

Hi,

Starting in 1.3 meson warns about using '@0@'.format(file). Previously that was, to my knowledge, the only way to get the file path of a file from configure_file() or files(). Now, clearly that wasn't intentionally supported, so I probably don't get to complain too much that that doesn't work anymore. However, there's not really any supported way of getting the filename from 'file', which isn't great.

For postgres I have two uses for wanting the filename for a 'file':

1. Checking that there no source tree files with the same name as configure_file(). Postgres historically (and for now still) supports building in-tree with autoconf/make and our homegrown msvc buildscripts. When that build is incompletely cleaned up, the old generated configuration files end up in the source tree, and will often get used by the compiler (there's to my knowledge no way to make a compiler to prefer a file in a different directory for #include "filename". This has lead to numerous odd build failures. Sometimes such failures happen way later, when the contents of the generated files have evolved. For that reason postgres meson build checks if there are any generated files with conflicting names in the source tree. There aren't that many configure_file()s, so I guess we can manually maintain the list of conflicting names, instead of getting them from the object returned by configure_file() (although the directory handling would be more complicated that way).

2. Generating custom_target() output names for source files in a lot of different directories. Unfortunately for the use case (compiling C files a second time, to LLVM IR, for JIT inlining), generators were too restrictive. Because we have source files with the same name in different directories, @BASENAME@ does not suffice to get non-conflicting output names. The current meson code looks like this:

  foreach srcfile : bitcode_module['srcfiles']
    srcfilename = '@0@'.format(srcfile)
    targetname = '@0@_@1@_@2@.bc'.format(
      bitcode_name,
      fs.parent(srcfilename).underscorify(), fs.name(srcfilename))
    bitcode_targets += custom_target(
      targetname,
...

Is there any chance to provide an alternative way to get the filename from a file, or to add 'file' to the list of types that are allowed to be formatted?

I also have repeatedly found it useful to be able to print the filename of a 'file' for error(), warning() etc. Afaict there's no way to do that anymore that doesn't trigger the new deprecation messages.

CC: @eli-schwartz

Regards,

Andres

[eli-schwartz]

Previously that was, to my knowledge, the only way to get the file path of a file from configure_file() or files(). Now, clearly that wasn't intentionally supported, so I probably don't get to complain too much that that doesn't work anymore. However, there's not really any supported way of getting the filename from 'file', which isn't great.

There's a bigger hole than that. You can't get the file path of that file even with the unsupported, currently-issues-a-warning approach. The best you can do is get the relative filepath "from either the source root or the build root, but you do not know which one".

I'm sure there were people depending on that, as well as people for whom it is a nasty surprise. Changing it seems inadvisable, but keeping it is also inadvisable, hence the deprecation... (this is not the only reason for me, but it is a big one).

[anarazel]

Well, deprecating it would make more sense if there were a replacement (like file.path() or such)... What are the chances of getting some replacement for the deprecated functionality into 1.3?

[xclaesse]

Adding file.full_path() makes sense IMHO.

[xclaesse]

@anarazel #12408