mpv/common/meson.build

version_h = vcs_tag(
    command: ['git',
        '--git-dir=' + join_paths(source_root, '.git'),
        '--work-tree=' + source_root,
        'describe', '--always', '--tags', '--dirty'],
    input: 'version.h.in',
    output: 'version.h',
    replace_string: '@VERSION@',
)

sources += version_h
build: remove version.py After second thought version.py does not do anything useful. Meson has built-in function vcs_tag that mostly replicate what version.py did. For the build time we can just use __DATE__ and __TIME__. Of course this changes time string format a little, but in my opinion it looks nicer in fact. Also it will use local time, instead UTC. But I would argue that date string is only informative for users to check how old the specific mpv build is. It doesn't have to be precise, it weren't for years anyway before recent change. 2023-07-30 10:34:55 +00:00			`version_h = vcs_tag(`
build: restrict git describe to top level source directory fix version determination when building mpv from release tarball extracted within another git repository 2023-11-21 20:53:16 +00:00			`command: ['git',`
			`'--git-dir=' + join_paths(source_root, '.git'),`
			`'--work-tree=' + source_root,`
			`'describe', '--always', '--tags', '--dirty'],`
build: remove version.py After second thought version.py does not do anything useful. Meson has built-in function vcs_tag that mostly replicate what version.py did. For the build time we can just use __DATE__ and __TIME__. Of course this changes time string format a little, but in my opinion it looks nicer in fact. Also it will use local time, instead UTC. But I would argue that date string is only informative for users to check how old the specific mpv build is. It doesn't have to be precise, it weren't for years anyway before recent change. 2023-07-30 10:34:55 +00:00			`input: 'version.h.in',`
			`output: 'version.h',`
			`replace_string: '@VERSION@',`
			`)`

			`sources += version_h`