Skip to content
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

Why does ctx.actions.args.param_file_arg accept a constant argument #10616

Closed
ittaiz opened this issue Jan 19, 2020 · 7 comments
Closed

Why does ctx.actions.args.param_file_arg accept a constant argument #10616

ittaiz opened this issue Jan 19, 2020 · 7 comments
Assignees
Labels
P2 We'll consider working on this in future. (Assignee optional) type: documentation (cleanup)

Comments

@ittaiz
Copy link
Member

ittaiz commented Jan 19, 2020

ATTENTION! Please read and follow:

  • if this is a question about how to build / test / query / deploy using Bazel, or a discussion starter, send it to [email protected]
  • if this is a bug or feature request, fill the form below as best as you can.

Description of the problem / feature request:

I'm now using ctx.actions.args.param_file_arg and U don't understand why we need to pass a constant argument ("%s"). If it's constant why not hide it from the user?

What's the output of bazel info release?

2.0.0

Have you found anything relevant by searching the web?

https://docs.bazel.build/versions/master/skylark/lib/Args.html#use_param_file

@laurentlb
Copy link
Contributor

The argument needs to contain %s, but it can be for example "@%s" or "--param_file=%s".

@ittaiz
Copy link
Member Author

ittaiz commented Feb 7, 2020

What do these options mean? Are they documented? I’m not trying to troll but I honestly don’t understand the API choice here

@ulfjack
Copy link
Contributor

ulfjack commented Feb 7, 2020

The question is: what does the tool you're calling expect?

If it's just the filename, then pass "%s". For gcc and clang, the tool expects "@%s". The '%s' substring is replaced with the filename, so for gcc, the invocation is actually "gcc @param-file". Does that make sense?

In some cases Bazel decides whether to use a param file on-the-fly depending on the actual size of the command line. I'm not sure if this API exposes that or if it can be controlled. Note that there is a Bazel build command-line flag to force it to always use param files.

@laurentlb
Copy link
Contributor

No worries, it just shows that the documentation needs improvement and examples.

If you take gcc, you can call it like this:

$ gcc hello.c -c

To use a params file, you will do instead:

$ echo "hello.c -c" > params.txt
$ gcc @params.txt

That's gcc command-line syntax. To pass a param file, you need to put @ and then the file.
Other tools might use different a convention, e.g. --file=params.txt.

So when you want to use a param file, you tell Bazel how to pass the argument to the tool, such as "@%s" or "--file=%s". Bazel will replace %s with the path to the file.

@ittaiz
Copy link
Member Author

ittaiz commented Feb 7, 2020

Thank you both for explaining!
Do you think there’s room for a default value here or is the landscape really diverse and so a default doesn’t make sense?

@laurentlb laurentlb added P2 We'll consider working on this in future. (Assignee optional) type: documentation (cleanup) and removed untriaged labels Feb 7, 2020
@laurentlb
Copy link
Contributor

It seems that @file is common among Linux tools (https://stackoverflow.com/a/13040192). Inside Google, most calls to param_file_arg use another value (but not always the same).

I think it's better not to have a default value. The user should really check with the tool is expecting. I'll keep this issue open as a documentation problem.

@ittaiz
Copy link
Member Author

ittaiz commented Feb 8, 2020

SGTM. Thanks for the clarifications.

@c-parsons c-parsons self-assigned this May 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 We'll consider working on this in future. (Assignee optional) type: documentation (cleanup)
Projects
None yet
Development

No branches or pull requests

5 participants