stip() function has no effect on @OUTPUT@ ?

[vpoinot]

I have the following snippet in my meson.build:

sqlite2cpp = find_program('sqlite2cpp', required: true)

schema = custom_target('generate-schema',
                       input: 'schema.sql',
                       output: 'schema',
                       command: [ sqlite2cpp, '-identity-naming', '@INPUT@', '@OUTPUT@', 'stox' ])

stox = executable('stox',
                  sources: [ 'main.cpp', src_core, src_backend, src_writers, src_helpers, schema ],
                  dependencies: boost)

Given the output = schema , the program sqlite2cpp will generate a file named schema.h (i.e. will add the extension). Problem: every time, I run meson compile, the custom target is re-run, and the file schema.h regenerated. My theory is that this is because the value of output does not match the name of the file that is actually generated.

In order to prove my theory, I did the following instead:

schema = custom_target('generate-schema',
                       input: 'schema.sql',
                       output: 'schema.h',
                       command: [ sqlite2cpp, '-identity-naming', '@INPUT@', '@OUTPUT@', 'stox' ])

Then I run meson compile, which generates a file schema.h.h; I manually rename this file to just schema.h and recompile: the target is not re-run. I believe this is because the output exactly matches the renamed generated file: from meson's perspective, there is nothing to do since the output is up-to-date.

So I wanted to go one step further:

schema = custom_target('generate-schema',
                       input: 'schema.sql',
                       output: 'schema.h',
                       command: [ sqlite2cpp, '-identity-naming', '@INPUT@', '@OUTPUT@'.strip('.h'), 'stox' ])

My intent was to tell meson that the output would be named schema.h, and have sqlite2cpp use the parameter schema so that it actually generates schema.h, matching the output. But it seems the strip() call does nothing: the command that is executed is:

meson compile -C build/clang/debug -v
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /home/vincent/devl/stox/build/clang/debug -v
ninja: Entering directory `/home/vincent/devl/stox/build/clang/debug'
[1/1] /usr/bin/python3 /home/vincent/devl/stox/subprojects/sqlpp11-0.64/scripts/sqlite2cpp.py -identity-naming ../../../schema.sql schema.h stox

so schema.h is passed on the command line. I tried to use replace() instead, to use @OUTPUT0, to no avail.

What's the trick? how can I achieve what I want, i.e. generate this schema.h once?

[eli-schwartz]

'@OUTPUT@'.strip('.h')

Is a string replacement function that results in the string '@OUTPUT@', which is in turn passed as an argument to the custom target. The custom target function itself specially handles string values containing replacement tokens.

The actual output you want here is @OUTDIR@/schema, essentially. All that @OUTPUT@ does specially is handle prepending the output directory to the same string you used as the output: kwarg.

You can use @OUTPUT@/@BASENAME@ to strip the .sql programmatically from the input filename, or just hardcode "schema" here.

I confess I'm surprised by this sqlite2cpp interface. Usually if a tool wants to choose the output filename itself it takes a directory argument, rather than taking the full path to the output filename but then appending the .h suffix on its own. If it doesn't want to choose the output filename, it just takes whatever you tell it.

[vpoinot]

Thanks, I had not realized that variables like @OUTPUT@ are evaluated by the custom target itself, i.e. too late for my code to work.
I went with your suggestion of using @OUTDIR@/@BASENAME@ which does the job.

I agree with you that this behaviour of sql2cpp is bit unusual; maybe the idea behind providing just a basename for the output (i.e. in my example "schema") is that in the future this name might serve for several outputs using this radix, e.g. both "schema.cpp" and "schema.h", or even several header files like "schema1.h", "schema2.h", etc. Just asking for the basename on the command line would let the implementer free to reorganize the final outputs...