It will break on ci.

@waruqi It seems that the CI error is exposed by my change but not caused by it, I sent a separate PR to fix it: #4

Do you have any suggestion about what to do for the string escaping of quotation marks?

Do you have any suggestion about what to do for the string escaping of quotation marks?

Check if it is \" and not automatically escape it?

Yep, I'll try that. I'm now dealing with another issue where one of the changes I made is breaking how other values are read out of the target map. Looking for a solution now.

@waruqi OK, I have solution that works now. Let me know if you think there are any possible issues with how I'm "escaping" the spaces in the define string. I'm using a sentinel value of ~!~ which hopefully should be uncommon. Happy to make further edits based on your suggestions.

That particular system configuration must not like the space in the -D flag somehow, I'll investigate a bit futher.

I tested it, it does not work for my xmake/tbox.

git clone https://github.com/tboox/tbox
./configure
make
make: *** Waiting for unfinished jobs....
src/tbox/utils/dump.c:39:5: error: use of undeclared identifier 'tbox'
    tb_trace_i("");
    ^

    add_defines "__tb_prefix__=\"tbox\""

Thanks! I'll adjust it and use your repo to verify.

OK, I'm not sure how to proceed here, let me see if I can explain the factors at play:

• The tbox repo depends on automatic quote escaping for add_depends so that "tbox" gets inserted as a string literal in the C source to be used for tracing messages
• My example needs to insert an unquoted string of C code (extern "C" ) into a header file via -D flag so that it can affect API signatures of the Dear Imgui library. If the outer quotes get auto-escaped, they will be inserted verbatim into the C code, causing a compiler error
• There isn't a way, as far as I know, to un-escape the quotes when they reach the -D flag in the makefile, so at this point I would need to introduce some kind of hack to make my scenario work (or just keep my own forked xmake.sh that works for me; not ideal)

In my opinion, the default behavior (always escaping quotes) might be surprising to users who want to pass a string containing spaces to a -D flag without the escaped quotes included.

My recommendation would be to remove auto-escaping and for xmake.sh targets that need to pass a quoted string to do it explicitly:

add_defines "__tb_prefix__=\\\"tbox\\\""

It's certainly uglier and slightly inconvenient, but at least it enables the configure script to enable all possible usages of add_defines. On the other hand, the tbox repo uses the __tb_prefix__ a number of times, so I'm reluctant to change how everything works just to enable my own scenario, though I think I'm not the only person who will run into this problem.

Do you think there's a reasonable way to solve this problem? How does the Lua version of xmake deal with this?

If you're willing to remove auto-escaping of defines strings, I'd be happy to go update the xmake.sh files in the tbox repo to use the additional escaping needed to make it work again. Do you know if this pattern is used in other repositories that might need to be updated too?

How does the Lua version of xmake deal with this?

For xmake, it does not splice arguments to generate a string command, but passes all the argument items directly into execv as a table list

so, string escaping can be avoided.

        add_defines "TEST=\"test\""
        add_defines "IMPL_API=extern \"C\" "

os.execv("gcc", {"TEST=\"test\"", "IMPL_API=extern \"C\" "})

xmake.sh is a lightweight version of the xmake implementation, it is not used to handle complex things. Calling string_replace on each defines entry is very slow, as it calls the sed subprocess every time.

so we need only use add_cxflags instead of add_defines for this special case.

        add_defines "TEST=\"${name}\""
        add_cxflags "-DIMPL_API=\"extern \\\"C\\\" \""

It works for me. I have improved it.

f54115a

OK, I'm fine with using add_cxflags for that purpose, thanks for the suggestion! It looks like those group of functions don't support {public} but I think I should be fine without it in this case.

I just tried it out in my project and add_cxflags works just fine. Thanks again! I'll close this PR for now.