Open mjj47 opened 2 years ago
We can definitely look to add specific escaping rules for $ORIGIN
in the compiler flags passed through to the build system. Are there any other 'magic' variables we need to be escaping in the compile flags or should we escape all instances of $
in compiler flags?
$ORIGIN
is definitely the main problem child within the build space I know of. I would imagine not wanting to escape all $
's... I occasionally want to rely on some of the build_script internal variables. (unless I'm using this improperly). Case where I like to use $:
configure_options =
select({
"@//tools:is_arm_build": [
"--config=$EXT_BUILD_ROOT/external/openssl_config/custom.conf",
"custom-linux-aarch64",
],
"//conditions:default": [
"--config=$EXT_BUILD_ROOT/external/openssl_config/custom.conf",
"custom-linux-x86_64",
],
I can add a :data_custom entry into data
and use $EXT_BUILD_ROOT within my configure script to get the input file.
Although, I admit this will be resolved prior to being passed to the compiler... Perhaps I am okay with y'all escaping all $'s sent to the compiler! (Wanted to at least throw in the above use case)
I just ran into the same issue (-Wl,rpath,$$ORIGIN/../lib
) with cmake and came to file an issue.
because rules_foreign_cc relies on a build_script.sh to wrap all the linker commands to building binaries, any path that is added as a linker argument with $ORIGIN in the rpath will fail at build time.
build_script.sh will see $ORIGIN and attempt to resolve the variable within the context of the bash script rather than piping the $ORIGIN string through to the linker.
As a workaround, I am setting the environment variable env = { "ORIGIN": "\$$\$$ORIGIN", },
in order to have rules_foreign_cc build_script.sh resolve $ORIGIN to \$\$ORIGIN so that the makefile will see $$ORIGIN which will be treated as a literal.
It would be much much much preferred if rules_foreign_cc could support an rpath with $ORIGIN embedded natively, without end user need for work arounds.