New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Permit __DATE__, __TIME__, etc in foreign builds #239
Comments
From the peanut gallery (not a maintainer): the problem seems to be that the double-quoting is being dropped. A literal |
I doubt you'd ever want to allow these, as they would change build artifacts all the time, which prevent any kinds of caching that bazel relies on. Try adding this: |
Yes, it seems as if the problem is that they're not escaped correctly. I don't know that it's important for apache - but if they're going to be fixed, I would suggest at least setting them to valid expansions in case there's code that parses them. |
I'm using
I don't found |
I ran into the very same error trying to compile php (yeah...) :
And in my local user
Update 1 :It's still compiling, but @UlysseM 's fix does seem to do the trick : Update 2 :Yes! It did help. Now I'll just have to dig through the rest of my problems. Workaround that worked for me@UlysseM 's fix : |
If i really need this macro, what could i do to disable bazel's replacement? I could bear some loss of performance, but i don't find some solutions so far. |
How can this replacement of those macros be disabled? There are use cases which can bear the performance hit but require this |
Due to bazelbuild/rules_foreign_cc#239, we elide usage of __DATE__ in RocksDB. It makes our life much easier when trying to bazel-ify the cockroachdb repo.
I'm also using |
@ilanbiala after a bemusing round of string-escape tetris, I have found a solution!
The same would hold for CXXFLAGS. |
This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_foreign_cc! |
The real problem here appears to be that the quoting seems to be different in the CMake and Configure/Make versions. Here is how ARFLAGS="rcsD" ASFLAGS="-U_FORTIFY_SOURCE -Wall -Wthread-safety -Wself-assign -fcolor-diagnostics -fno-omit-frame-pointer -fstack-protector -D__DATE__=\"redacted\" -D__TIME__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -Wno-builtin-macro-redefined -no-canonical-prefixes" CFLAGS="-U_FORTIFY_SOURCE -Wall -Wthread-safety -Wself-assign -fcolor-diagnostics -fno-omit-frame-pointer -fstack-protector -D__DATE__=\"redacted\" -D__TIME__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -Wno-builtin-macro-redefined -no-canonical-prefixes -DDATE='\"redacted\"' -DTIME='\"redacted\"'" CXXFLAGS="-U_FORTIFY_SOURCE -Wall -Wthread-safety -Wself-assign -fcolor-diagnostics -fno-omit-frame-pointer -fstack-protector -std=c++17 -D__DATE__=\"redacted\" -D__TIME__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -Wno-builtin-macro-redefined -no-canonical-prefixes" LDFLAGS="-B${EXT_BUILD_ROOT}/external/llvm/bin --ld-path=${EXT_BUILD_ROOT}/external/llvm/bin/ld.lld -Wl,-no-as-needed -Wl,-z,relro,-z,now -lstdc++ -lm -no-canonical-prefixes -L$EXT_BUILD_DEPS/ffi_lib/lib -L$EXT_BUILD_DEPS/mpdecimal_lib/lib -L$EXT_BUILD_DEPS/z_lib/lib -L$EXT_BUILD_DEPS/openssl_lib/lib" AR="/.${EXT_BUILD_ROOT}/external/llvm/bin/llvm-ar" CC="/.${EXT_BUILD_ROOT}/external/llvm/bin/clang" CXX="/.${EXT_BUILD_ROOT}/external/llvm/bin/clang" CPPFLAGS="-I$EXT_BUILD_DEPS/ffi_lib/include -I$EXT_BUILD_DEPS/mpdecimal_lib/include -I$EXT_BUILD_DEPS/z_lib/include -I$EXT_BUILD_DEPS/openssl_lib/include" "$EXT_BUILD_ROOT/external/lib_python/configure" --prefix=$BUILD_TMPDIR/$INSTALL_PREFIX --disable-shared --with-openssl="${EXT_BUILD_DEPS}/openssl_lib" --with-system-libmpdec While
Note the defines: |
One workaround I found was to have This works until the quoting can be mode more consistent. A good example that uses |
Hopefully the quoting is correct now for CMake based builds. The quotes Unfortunately for For those asking about disabling this - these redactions are configured as part of the cc_toolchain; if you want to turn it off you need to define your own toolchain to do this. If you need help in doing so I'd suggest that you ask on the bazel-discuss mailing list or in the bazel slack. |
For anyone reading the previous comment, here is a quick link to how one might enable/disable these in the |
This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_foreign_cc! |
I submitted a PR (bazelbuild/bazel#14735) to be able to remove all default flags from the built-in cc toolchains. I submitted it 4 months ago and it still hasn’t been reviewed yet 😔 |
This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_foreign_cc! |
@jheaff1 FYI looks like your upstream PR was merged. |
Yep glad to see it’s in Bazel 6.0! |
Given bazelbuild/bazel#14735 is merged and there's not a lot we can do about the quoting situation as different build scripts require different styles of quoting, I'm going to close this now. |
One problem of using 'configure_options' like this is that CFLAGS are being redefined, overriding the toolchain flags entirely. Are there less invasive ways to do it? |
Another library that seems to break due to the quoting here is gmp, which generates a
|
I'm using
configure_make
with apache and get this errorbecause of the options
Could those be disabled by default for these external builds?
The text was updated successfully, but these errors were encountered: