-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Autoconfigured unix crosstool should respect standard environment variables #5186
Comments
This is currently blocked by:
|
I think there is no need to restrict this to Unix only. CMake on Windows will honour I am willing to implement the Windows part later. I have some other improvements to upstream after C++ Crosstool migration is done. |
Good points. We have to bring our windows and darwin-with-Xcode toolchains to the same level of configurability as unix toolchain is. |
Can you tell me when this is going to be implemented? I'm currently evaluating Bazel as replacement for our existing CMake setup but the configuration of cross toolchains is way too complicated. We could generate the necessary files from our Yocto environment but as there is already a environment setup script written by Yocto containing the CC/CXX/etc. paths and flags it would be good if Bazel could work with that instead. Please note that Bazel must be able to accept CC/CXX paths with additional compiler flags appended because this is how Yocto inserts the sysroot and some architecture flags. Here is an example:
|
@jasal82 I'm not sure for the timing, its got a few deps that arn't done yet i think. In the mean time, I do this, feel free to copy. Its kind of ugly but it works decently well. /~https://github.com/gentoo/gentoo/blob/0d7adf51d80763d2ca8c3e5ffac4dd9b3edbe388/sci-libs/tensorflow/tensorflow-1.11.0_rc0.ebuild#L125-L141 |
@perfinion Your sample code is setting the compiler flags but I don't see where the cross compiler binaries are configured. Maybe I'm missing something. |
+1 please |
Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team ( |
This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team ( |
Autoconfigured C++ toolchain doesn't follow standard gnu environment variables. There is no reason why we couldn't use the standard, therefore let's do it.
Bazel currently inspects some environment variables, but those don't have standard naming (even within bazel), are hard to discover (you have to go read the source code) and are completely undocumented.
Since gnu env vars are widely understood, using them would lower the entry barrier plus would make the life of package maintainers simpler, as they would not have to special case packages built by bazel.
This is very simple to implement, the cost is mostly the need to migrate existing users.
The most important environment variables are:
Flags for the programs:
CFLAGS,CXXFLAGS: these are passed right after $CC for any optimizations and
$(CC) $ (CFLAGS) foo.c -o foo.o. You are more than welcome to
whatnot, make's implicit compile rule basically does:
append to any of these variables just overwriting is problematic.
LDFLAGS: These are the flags for the linker itself.
LDLIBS: these are the libraries that the binary needs to be linked
$(LD) $ (LDFLAGS) -o out foo.o bar.o $(LDLIBS). mixing up LDFLAGS
against. Basically stuff with -l goes in LDLIBS and stuff with
-L goes in LDFLAGS. make's rules for linking are roughly:
and LDLIBS causes issues when --as-needed is used too.
SYSROOT: this is for cross-compiling and autoconf passes it as gcc
--sysroot= i think. I don't cross-compile that often but can get
you more info if it'd help.
The text was updated successfully, but these errors were encountered: