question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

A better "executable" mechanism

See original GitHub issue

This is a feature request for a better mechanism than setting “executable = True” on a rule.

There are a few issues with the current mechanism.

  1. Name transformations (.exe, .sh, .bat etc) are not under the control of the rule This is a problem for things like cross compiling to windows, which is one of the major drivers for this issue. The Kubernetes team need linux to windows cross compile and there is no way for me to make it work right now.

  2. Multiple binary flavours You can easily build multiple flavours (static, asan, etc) of an output rule using various controls (output groups, features etc) but you cannot easily control which of them is the default output used by bazel run or (even worse) bazel test. What you have to do right now is build them with flavour specific names and then have an extra rule to copy the flavour version over the pre-determined output path.

  3. Your rule name is forced by your desired binary name This leads to weirdness where you don’t really want a rule to be called the same as the binary, for instance if the default rule for a package should be to build and package an executable, but you really want the executable named the same as the folder.

  4. It’s weird extra magic You can do everything else about selecting your outputs in a standard way except this one thing and I don’t think it deserves or needs the conceptual overhead.

Instead of this I propose we add a new provider, either an extra one or a well understood field of the DefaultOutputProvider.

For example, currently we would write:

def _my_binary_impl(ctx):
  normal_executable = ctx.outputs.executable
  ...
  return [
      DefaultInfo(
          files = depset([normal_executable]),
      ),
      OutputGroupInfo(
          normal = depset([normal_executable]),
          static = depset([static_executable]),
          asan = depset([asan_executable]),
      ),
  ]

my_binary = rule(
    _my_binary_impl,
    attrs = {
        "srcs": attr.label_list(allow_files = True),
        "deps": attr.label_list(),
    },
    executable = True,
)

And instead this would become:

def _my_binary_impl(ctx):
  normal_executable = ctx.actions.declare_file(ctx.label.name)
  ...
  return [
      DefaultInfo(
          files = depset([normal_executable]),
          executable = normal_executable,
      ),
      OutputGroupInfo(
          normal = depset([normal_executable]),
          static = depset([static_executable]),
          asan = depset([asan_executable]),
      ),
  ]

my_binary = rule(
    _my_binary_impl,
    attrs = {
        "srcs": attr.label_list(allow_files = True),
        "deps": attr.label_list(),
    },
)

There is probably a cost in that the rule type alone is no longer sufficient to tell you if it is executable and if so what file you are going to execute?

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:16 (16 by maintainers)

github_iconTop GitHub Comments

1reaction
ianthehatcommented, Oct 25, 2017

Tested this today, worked perfectly for this and a few other use cases, thanks!

0reactions
dslomovcommented, Oct 25, 2017

Great, let me know it you hit any issues, and thanks for bringing this problem to our attention and also suggesting a design for solution. This will be helpful to everyone developing rules for Windows.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Better executable path queries in GHC 9.4 - GitHub Pages
getExecutablePath :: IO FilePath is a way for a Haskell program to query the path to its own executable. It has several significant...
Read more >
Executable Program - an overview | ScienceDirect Topics
There is a mechanism, via the ONLY keyword, that allows just a selection of variables to be ... EXE format tend to be...
Read more >
Position Independent Executables (PIE) - Red Hat
Position Independent Executables (PIE) are an output of the hardened package build process. A PIE binary and all of its dependencies are ...
Read more >
Position-independent code - Wikipedia
In computing, position-independent code (PIC) or position-independent executable (PIE) is a body of machine code that, being placed somewhere in the primary ...
Read more >
Submitting Jobs Without a Shared File System
The HTCondor file transfer mechanism allows the user to explicitly select which ... These files are placed in the same directory as the...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found