You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Potentially symlink runfiles together with the tools into bin (#1434)
When using foreign_cc configure_make rule it generates a script that
symlinks the tools needed by the build into a bin directory that is
added to PATH later (at lest when configure_in_place is used).
When using host autotools, that step may not be very important since the
tools are available in the PATH anyways, but with hermetic autotools
it's quite important to make sure that autogen/configure use hermetic
autotools and not whatever is available at the host.
Various tools in autotools suite need some data to run though (e.g.,
autom4te.cfg or definitions of m4 macroses). When building autotools in
Bazel (or wrapping prebuilt autotools), that data will be provided as
runfiles, so we need to make those runfiles available along with
hermetic autotools.
To access runfiles, Bazel ecosystem provides a bunch of libraries for
various languages that allow to find the runfiles the tools need.
Without going into details of how those libraries work, the basic
principle is to probe filesystem for runfiles directory or runfiles
manifest in the directory with the running tool itself.
As a result, when we symlink the tool into a bin directory and call the
tool via that symlink, the tool will look into a wrong place for
runfiles.
I had two ideas of how to deal with that issue:
1. [Implemented in this change] Just symlink the runfiles together with
the tools into the bin directory that will later be added to the PATH
2. Wrap the tool into a script that will resolve its own symlink name to
the actual filesystem location.
Why did I chose the first option over the second one?
Basically, it seems like foreign_cc supports multiple different OSes and
I only have Linux to test it on, with that relying on the existing
infrastructure is likely to produce a result working for other systems.
To put it another way, I don't actually know how to resolve a symlink on
Windows and if I found the way, I would not be able to test it.
There is an additional minor reason why I favour the first option over
second one - there are alternatives to symlinking here, for example,
using hard links or just plain copies instead. It's hard to tell what
will happen in the future, but if at some point we decide to switch to
copies or hard links instead, resolving the symlink in the wrapper
script will stop working, so symlinking runfiles seems like a more
future proof option.
What do we need to symlink? To figure that out, I just looked at the
runfiles library for Bash. The runfiles library basically looks at
runfiles directory which is called <tool name>.runfiles or a runfiles
manifest file which is called <tool name>.runfiles_manifest or <tool
name>.exe.runfiles_manifest, so these are the things we need to symlink
along withg the tools themselves.
If those directories or files do not exist, symlink will fail, but the
failure is not fatal - it will produce a warning, but the build will
continue.
Tracked in #755
+cc @jsharpe
Signed-off-by: Mikhail Krinkin <[email protected]>
0 commit comments