What does this mean in Bazel's documentation:
Add the code below to the BUILD or BUILD.bazel file in the root
directory of your repository. Replace the string after prefix with the
prefix you chose for your project earlier.
load("#bazel_gazelle//:def.bzl", "gazelle")
# gazelle:prefix github.com/example/project
gazelle(name = "gazelle")
There is a sentence "Replace the string after prefix with the prefix you chose for your project earlier", my project is D:\workspace\www\go_work\src\golang_learning,how to set it?
The wording implies you chose a prefix earlier; it looks like the documentation could use a bit of improvement, especially for those new to go - I don't see anything above that explaining the prefix they're talking about.
One way to think of this prefix is "the part of the path remaining when you strip off $GOPATH/src/". Based on the path you provide, this should be golang_learning, so change the gazelle:prefix line to
# gazelle:prefix golang_learning
and you should be good to go.
Related
Is there a way to control the Bazel build to generate wanted temp files for a list of source files instead of just using the command line option "--save_temps"?
One way is using a cc_binary, and add "-E" option in the "copts", but the obj file name will always have a ".o". This kind of ".o" files will be overwriten by the other build targets. I don't know how to control the compiler output file name in Bazel.
Any better ideas?
cc_library has an output group with the static library, which you can then extract. Something like this:
filegroup(
name = "extract_archive",
srcs = [":some_cc_library"],
output_group = "archive",
)
Many tools will accept the static archive instead of an object file. If the tool you're using does, then that's easy. If not, things get a bit more complicated.
Extracting the object file from the static archive is a bit trickier. You could use a genrule with the $(AR) Make variable, but that won't work with some C++ toolchains that require additional flags to configure architectures etc.
The better (but more complicated) answer is to follow the guidance in integrating with C++ rules. You can get the ar from the toolchain and the flags to use it in a custom rule, and then create an action to extract it. You could also access the OutputGroupInfo from the cc_library in the rule directly instead of using filegroup if you've already got a custom rule.
Thanks all for your suggestions.
Now I think I can solve this problem in two steps(Seems Bazel does not allow to combine two rules into one):
Step1, add a -E option like a normal cc_libary, we can call it a pp_library. It is easy.
Step2, in a new rules, its input is the target of pp_library, then in this rule find out the obj files(can be found via : action.outputs.to_list()) and copy them to the a new place via ctx.actions.run_shell() run_shell.
I take Bazel: copy multiple files to binary directory as a reference.
I'm writing some validation code for a bazel build rule and I need to do some path validation. I need to check that a certain file exists in the same directory as the BUILD file. I notice that there's a context attribute build_file_path which points to the BUILD file. I'd like to extract the parent directory from this.
It looks like I can't create a new path object - I don't see a constructor/initializer. It also seems like Starlark doesn't support os.path like python because imports aren't supported.
What's the canonical way to get the parent directory of a string object representing a path in Starlark?
I can't answer your final question, but hopefully the following will help with the initial problem:
You could use the Label of the target for which this instance of the rule is being built and find its package. This will give you a string representing the parent directory of the BUILD file.
i.e. ctx.label.package
load("#bazel_skylib//lib:paths.bzl", "paths")
paths.dirname(path_str)
See https://github.com/bazelbuild/bazel-skylib/blob/main/docs/paths_doc.md
I use flume-1.8.0.
On the document, it says that I cannot set the directory pattern.
(Regular expression (and not file system patterns) can be used for filename only.)
But I have to set the directory pattern to get log from other system which controlled by other team.
Is there some solution to set directory path like /dir/201801/0101.log, /dir/201802/0001.log, ... ?
Use something like this for the file groups with file patterns i.e use the Regex ASCII pattern see https://en.wikipedia.org/wiki/Regular_expression for more details
a1.sources.r1.filegroups.f2 = /path/to/files/with/pattern/databundle_cnt_[0-9]{4}-[0-9]{2}-[0-9]{2}.csv
In your case I will advise
a1.sources.r1.filegroups.f2 = /dir/[0-9]{6}/[0-9]{4}.log
Is it possible using .tfignore to add a wildcard to directories? I assumed it would have been a case of just adding an asterisk wildcard to the directory segment. For example:
\path\*\local.properties
However this does not work and I am unsure how I would achieve such behaviour without explicitly declaring every reference that I need excluding. .
Documentation
# begins a comment line
The * and ? wildcards are supported.
A filespec is recursive unless prefixed by the \ character.
! negates a filespec (files that match the pattern are not ignored)
Extract from the documentation.
The documentation should more correctly read:
The * and ? wildcards are supported in the leaf name only.
That is, you can use something like these to select multiple files or multiple subdirectories, respectively, in a common parent:
/path/to/my/file/foo*.txt
/path/to/my/directories/temp*
What may work in your case--to ignore the same file in multiple directories--is just this:
foo*.txt
That is, specify a path-less name or glob pattern to ignore matching files throughout your tree. Unfortunately you have only those two options, local or global; you cannot use a relative path like this--it will not match any files!
my/file/foo*.txt
The global option is a practical one because .tfignore only affects unversioned files. Once you add a file to source control, changes to that file will be properly recognized. Furthermore, if you need to add an instance of an ignored name to source control, you can always go into TFS source control explorer and manually add it.
It seems this is now supported
As you see I edited tfignore in the root folder of the project such that any new branch will ignore its .vs folder when being examined for source control changes
\*\.vs
Directory/folder name wildcarding works for me in VS2019 Professional. For example if I put this in .tfignore:
*uncheckedToTFS
The above will ignore any folder named ending with "uncheckedToTFS", regardless of where the folder is (it doesn't have to be top level folder, can be many levels deep).
I have a doubt about indicating a path in makefile and I'd like to have a clarification.
Suppose my structure is made this way:
/home/machinename/softwarefolder/mainfolder
--------------------------------------------> /subfolder1
--------------------------------------------> /subfolder2
This means that both subfolder1 and subfolder2 are at the same nesting level in /mainfolder.
Now I'm compiling something inside subfolder 2 (this means that I cd to that folder) that uses a configure file with a macro pointing to a path that, in my case, it's in subfolder1.
This configure file used by the program in subfolder2 to compile is generated automatically by the program itself after running ./configure
The automatically generated configure file has the macro defined this way
MACRO = ../subfolder1
Do the two dots (..) indicate, as in the cd command, "go back one step" (and, therefor, the configure file is pointing to the right folder)?
If the answer to the first question is "no", then why substituting the aforementioned macro with
MACRO = /home/machinename/softwarefolder/mainfolder/subfolder1
generates a "missing separator" error in compile-time?
Sorry for the probably trivial question and thanks for the help!
Make doesn't interpret the content of variables in any way, for the most part. The question of how the .. will be interpreted depends entirely on where the variable is used. If it's used in a place where a path like ../subfolder1 makes sense, then that's how it will be interpreted. If not, not.
Since you don't show how $(MACRO) is used, we can't help. But in general the answer to your question is "yes, it means go up to the parent directory".
As for your second question, there is no way I can envision that changing just that one line will result in a "missing separator" error. Maybe your editor "helpfully" made other changes to the file such as removing TABs and substituting spaces, or adding TABs? TAB characters are special in makefiles.
If you want help with the second question you must provide (a) the exact error you received (cut and paste is best), and (b) the exact text of the rule in the makefile at the line number specified in the error message.