Add `@CURRENT_SOURCE_DIR@` to `custom_command`

[mdegans]

Describe the bug
Continuing from #7511

There may be a possible regression with 0.57 where @CURRENT_SOURCE_DIR@ has been removed from custom_target. I realize that's not in the manual, but removing CURRENT_SOURCE_DIR broke my build and I can't figure out a working replacement.

0.56.2 generates this build.ninja

...
build proto/settings.pb.cc: CUSTOM_COMMAND ../proto/settings.proto | /usr/bin/protoc
 COMMAND = /usr/bin/protoc --proto_path=../proto --cpp_out=proto ../proto/settings.proto
 description = Generating$ settings_pb_cc$ with$ a$ custom$ command

build proto/settings.pb.h: CUSTOM_COMMAND ../proto/settings.proto | /usr/bin/protoc
 COMMAND = /usr/bin/protoc --proto_path=../proto --cpp_out=proto ../proto/settings.proto
 description = Generating$ settings_pb_h$ with$ a$ custom$ command
 ...

0.57 generates:

build proto/settings.pb.cc: CUSTOM_COMMAND ../proto/settings.proto | /usr/bin/protoc
COMMAND = /usr/bin/protoc --proto_path=@CURRENT_SOURCE_DIR@ --cpp_out=proto ../proto/settings.proto
description = Generating$ settings_pb_cc$ with$ a$ custom$ command

build proto/settings.pb.h: CUSTOM_COMMAND ../proto/settings.proto | /usr/bin/protoc
COMMAND = /usr/bin/protoc --proto_path=@CURRENT_SOURCE_DIR@ --cpp_out=proto ../proto/settings.proto
description = Generating$ settings_pb_h$ with$ a$ custom$ command

To Reproduce

meson.build

protobuf = dependency('protobuf', version: '>=3.0.0')
protoc = find_program('protoc')

# many thanks to @marcelhollerbach for his solution.
# https://github.com/mesonbuild/meson/issues/7511#issuecomment-665470520

settings_pb_cc = custom_target('settings_pb_cc',
  input: ['settings.proto'],
  output: ['@BASENAME@.pb.cc'],
  command: [
    protoc,
    '--proto_path=@CURRENT_SOURCE_DIR@',
    '--cpp_out=@OUTDIR@',
    '@INPUT@',
  ]
)

settings_pb_h = custom_target('settings_pb_h',
  input: ['settings.proto'],
  output: ['@BASENAME@.pb.h'],
  command: [
    protoc,
    '--proto_path=@CURRENT_SOURCE_DIR@',
    '--cpp_out=@OUTDIR@',
    '@INPUT@',
  ],
  install: true,
  install_dir: get_option('includedir') / meson.project_name(),
)

settings_incdir = include_directories('.')

libazabacheproto = library(meson.project_name() + 'proto', settings_pb_cc,
  version: meson.project_version(),
  dependencies: protobuf,
  # FIXME(mdegans): remove this when moving to a 20.04 rootfs with new protobuf
  # becuase of this bug: https://github.com/protocolbuffers/protobuf/issues/4628
  cpp_args: ['-Wno-unused-parameter'],
  install: true,
)

azabacheproto_dep = declare_dependency(
  link_with: libazabacheproto,
  include_directories: include_directories('.'),
  dependencies: protobuf,
)

# generate a separate .pc for just the protobuf code.
pkg = import('pkgconfig')
azabacheproto_pc = pkg.generate(libazabacheproto,
  description: 'Azabache Camera Metadata Library',
  url: project_url,
  # for consistency with existing cmake install:
  install_dir: get_option('datadir') / 'pkgconfig',
  subdirs: meson.project_name(),
)

Any setttings.proto should do.

As a workaround, i tried '--proto_path=' + meson.current_source_dir(), but this doesn't seem to do the same thing. protoc does not like absolute paths, apparently:

[1/56] Generating settings_pb_cc with a custom command
FAILED: proto/settings.pb.cc 
/usr/bin/protoc --proto_path=/home/user/Projects/lib-azabache/proto --cpp_out=proto ../proto/settings.proto
../proto/settings.proto: File does not reside within any path specified using --proto_path (or -I).  You must specify a --proto_path which encompasses this file.  Note that the proto_path must be an exact prefix of the .proto file names -- protoc is too dumb to figure out when two paths (e.g. absolute and relative) are equivalent (it's harder than you think).
[2/56] Generating settings_pb_h with a custom command
FAILED: proto/settings.pb.h 
/usr/bin/protoc --proto_path=/home/user/Projects/lib-azabache/proto --cpp_out=proto ../proto/settings.proto
../proto/settings.proto: File does not reside within any path specified using --proto_path (or -I).  You must specify a --proto_path which encompasses this file.  Note that the proto_path must be an exact prefix of the .proto file names -- protoc is too dumb to figure out when two paths (e.g. absolute and relative) are equivalent (it's harder than you think).
[3/56] Compiling C++ object src/libazabache-0.1.so.p/encoder.cpp.o
FAILED: src/libazabache-0.1.so.p/encoder.cpp.o 

Expected behavior
@CURRENT_SOURCE_DIR in custom_target to be replaced with the crurrent source dir, or for there to be a usable replacement. Per the referenced issue, generator was unsuitable for this task. I'm using custom target, actually two of them, since I couldn't figure out a cleaner way.

system parameters

• plain, native build
• Ubuntu 18.04 aarch64 (Tegra)
• Python 3.6.9
• meson 0.57
• ninja 1.8.1

[eli-schwartz]

If the documentation enumerates allowed replacements and you use something not on that list, you're explicitly relying on meson having a BUG whereby a leaky abstraction inadvertently exposes something it shouldn't.

Therefore, this cannot be a regression.

[mdegans]

If the documentation enumerates allowed replacements and you use something not on that list, you're explicitly relying on meson having a BUG whereby a leaky abstraction inadvertently exposes something it shouldn't.

Therefore, this cannot be a regression.

Understood, @eli-schwartz . Can you suggest a replacement to a relative path to the source dir in such a case? Any way at all to generate source from protobuf and then build it?

The reason i was using @CURRENT_SOURCE_DIR@ was that I was using generator before. In the referenced issue it was suggested i used custom_target instead (with @CURRENT_SOURCE_DIR@). I was happy it was just working, but now it's not. For my case, and for those who might google, this, it would help to have a solution.

[eli-schwartz]

The way I see it, you have 3 possibilities:

• formally request @CURRENT_SOURCE_DIR@ support
• figure out some way for protoc to be content with absolute paths
• wait for Add fs.relative_to() function. Closes #2184 #7908 and use that to transform an absolute path to a relative one?

Previous uses I've seen for injecting the source directory into a custom target command line have all been perfectly okay with absolute paths, so idk why protoc dislikes this.

[mdegans]

Thanks for your suggestions, @eli-schwartz

• How/Where might i formally request @CURRENT_SOURCE_DIR@ support? Just file another issue here as a feature request?
• I don't think Google will change protoc, unfortunately. protoc is very opinionated about paths. I assume there are good reasons. I believe the "it's harder than you think" warning.
• That's probably what i'll end up going with if your first suggestion is out of the question. I'll keep an eye out for the fs module.

[eli-schwartz]

This issue, reworded, can be that feature request. :)

[mdegans]

Thanks, @eli-schwartz !

[jpakkane]

Note that CURRENT_SOURCE_DIR does work for generators: https://github.com/mesonbuild/meson/blob/master/test%20cases/frameworks/5%20protocol%20buffers/meson.build

There is no particular reason why it could not work for custom targets, too. It may have been removed by accident if there were no tests for it.

[xclaesse]

There are millions of subtle inconsistencies in what is supported in add_*_script(), run_target(), custom_target(), and generator(). I'm working on refactoring them all to use as much as possible the same code path there: #8342.

That refactor is for 0.58, not sure we want a "fix" for 0.57 since it was never documented...

[mdegans]

Just in case anybody is in my position and wants to revert the change, It seems paths were replaced in 0.56 by this line in the ninja backend, but this was removed by this commit.

That would seem to imply @CURRENT_SOURCE_DIR@ (and more) used to work a bunch of places it wasn't documented to.

[xclaesse]

@mdegans Indeed, also notice how replace_paths() does not exist in vs2010backend.py, so those never worked there.

[xclaesse]

Ok, should be covered by #8363.