How to get the path(s) from a files object?

[keeferrourke]

I'd like to avoid duplicating things in my build scripts, so where possible, I'd like to obtain the canonical paths from a files() object so that I can use these definitions.

Is there a way to do this? I couldn't find it anywhere in the documentation.

I'm looking for something akin to Python's pathlib.Path I suppose.

[gilzoide]

Just stumbled across this same problem, although with the returned object from configure_file().
It turns out you can use '@0@'.format(file) to grab it's path.
This also works with files() output as well when you index it like files[0] or within a foreach loop.

(maybe I'm a little late, but commenting for future record...)

[eli-schwartz]

What is this needed for? Generally, you can just use the objects themselves and they'll do the right thing.

[gilzoide]

Having String objects rather than File objects is useful if you plan to call string methods on it.
One can then generate any string based on the names, like target names for custom targets, arguments for custom commands/CLI programs, etc.

In my personal use case, I had a configure_file output that I needed to pass to emcc's --embed-file flag at linking time (was using configure_file to copy files, although in the end I changed this for calling cp or copy in a custom_target).
From what I remember, it just wouldn't accept the File objects directly.

textures = files(
  ...
)

foreach texture : textures
  tex_target = configure_file(input: texture, output: '@PLAINNAME@', copy: true)
  if host_machine.system() == 'emscripten'
    # embed files in web build, or else textures cannot be opened
    link_args += ['--embed-file', '@0@'.format(tex_target)]
  endif
endforeach

executable('name',
  sources,
  link_args: link_args,
  ...
)

[xclaesse]

From an implementation POV, I think it is now really easy to implement because we have FileHolder class that allows adding API on it. That's one of the nice things we get from the recent Holder refactoring.

[QuLogic]

If link_args doesn't accept File as a separate argument, that's a bug that should be fixed directly.

[PyroAVR]

I realize I'm late to this discussion, but at least as of Meson 0.55.3, add_project_link_arguments and the link_args argument of executable do not accept file objects.

../meson.build:112:4: ERROR: Link_args arguments must be strings.

A full log can be found at /gamerlights/dist/meson-logs/meson-log.txt
FAILED: build.ninja

[pwithnall]

This is more of a problem (for me) with Meson 1.3.0, as now the workaround code gives the error:

DEPRECATION: Project uses feature that was always broken, and is now deprecated since '1.3.0': str.format: Value other than strings, integers, bools, options, dictionaries and lists thereof..

Changing it to '@0@'.format(file.full_path()) changes the error to:

ERROR: Unknown method "full_path" in object <[FileHolder] holds [File]: <File: gio/gfiledescriptorbased.h (not built)>> of type FileHolder.

I can’t find a way out of this hole.

[pwithnall]

OK that seems to have been fixed by commit 85e4ee5 on master, but since that new API will only be available in Meson 1.4.0, that leaves this code uncompilable in Meson 1.3 if deprecation warnings are enabled, as far as I can tell

[eli-schwartz]

Deprecation warnings are, by themselves, just warnings. You can ignore the warning and it won't change your build results.

However it is a general sign that your build may have been broken all along, since the python-level __str__ / __repr__ values aren't guaranteed to have any meaning at all and are definitely not full-path aware. Depending on where and how you use them, the results may be entirely broken, or may work by accident.

The full_path method is always equal to meson.current_source_dir() / 'the-input-arg' (or current_build_dir for configured files), so you may use that regardless of meson version.

[pwithnall]

Deprecation warnings are, by themselves, just warnings. You can ignore the warning and it won't change your build results.

Sure, I know that, but it’s a bug in Meson if it’s putting out a warning and it’s not possible to avoid that warning in my project. As an aside, it would be helpful if Meson gave more advice about how to fix a deprecation warning when it prints one (e.g. link to a docs page which documents the deprecation and suggests common ways of doing the right thing instead). I can file that as a separate bug if that would be helpful?

However it is a general sign that your build may have been broken all along, since the python-level __str__ / __repr__ values aren't guaranteed to have any meaning at all and are definitely not full-path aware. Depending on where and how you use them, the results may be entirely broken, or may work by accident.

The build definitely worked before, but as you say this was apparently by accident.

The full_path method is always equal to meson.current_source_dir() / 'the-input-arg' (or current_build_dir for configured files), so you may use that regardless of meson version.

That’s the point of my comment: it doesn’t seem to be possible to use File.full_path() regardless of meson version, because of:

ERROR: Unknown method "full_path" in object <[FileHolder] holds [File]: <File: gio/gfiledescriptorbased.h (not built)>> of type FileHolder.

[eli-schwartz]

Sure, I know that, but it’s a bug in Meson if it’s putting out a warning and it’s not possible to avoid that warning in my project.

Without getting into whether this is a bug or not, you originally said it is "uncompilable", and that is all I was disagreeing about.

As an aside, it would be helpful if Meson gave more advice about how to fix a deprecation warning when it prints one (e.g. link to a docs page which documents the deprecation and suggests common ways of doing the right thing instead). I can file that as a separate bug if that would be helpful?

Maybe. What should we do about other deprecation warnings?

[pwithnall]

Sure, I know that, but it’s a bug in Meson if it’s putting out a warning and it’s not possible to avoid that warning in my project.

Without getting into whether this is a bug or not, you originally said it is "uncompilable", and that is all I was disagreeing about.

Ah yes, fair point, my wording was incorrect there. :)

As an aside, it would be helpful if Meson gave more advice about how to fix a deprecation warning when it prints one (e.g. link to a docs page which documents the deprecation and suggests common ways of doing the right thing instead). I can file that as a separate bug if that would be helpful?

Maybe. What should we do about other deprecation warnings?

I was thinking maybe have a docs link for each/every deprecation warning? The docs could be more or less expansive depending on how trivial the deprecation warning is (e.g. is it a like-for-like replacement with a different function call, or does it require people to rework their meson.build to use types differently?).

Shall I file an issue about it for further discussion?

[eli-schwartz]

Shall I file an issue about it for further discussion?

Sure. Can't hurt.

[pwithnall]

Shall I file an issue about it for further discussion?

Sure. Can't hurt.

⇒ #12689, sorry for the festive delay

[vcunat]

The full_path method is always equal to meson.current_source_dir() / 'the-input-arg' (or current_build_dir for configured files), so you may use that regardless of meson version.

/ doesn't accept a file as the second argument (and many other places, e.g. environment.set). We have foreach loops that involve files, for example.

Now the devs will be stuck with fat red deprecation messages locally, as obviously we can't yet use a feature that won't reach many distros for years, and though I tried hard, I fail to see another way.

[eli-schwartz]

if meson.version().version_compare('>=1.4')
    p = that_file.full_path()
else
    # this emits a deprecation warning ONLY on 1.3, not on previous versions
    # also it's not obvious what the actual resulting value is
    p = meson.current_source_dir() / '@0@'.format(that_file)
endif

You're stuck with the deprecation warning for 1.3 anyways since we can't change how an already released version works.

[vcunat]

Oh, thanks, conditionals like this can be done to cover both. I don't know why I thought that deprecations would be emitted even for if-branches that weren't taken.

[eli-schwartz]

Once upon a time they were emitted. This bothered someone, who did a bit of clever coding to locally override the meson_version in a restorable context whenever you enter an if block.

It's a beautifully dirty hack because it involves having a dedicated node type for strings depending on whether they are the result of a specific function call (the meson.version() one).

I forget exactly which version that was implemented. It was a while ago, but against meson's lengthy history it wasn't that long ago.