Is there any importance of order of paths exists in dcc32.cfg? can we modify the order or can add some more paths to it as per our convenience?
Actually I have list of programs which are interdependent and I compile all of them using command line compiler.
So in this process does it checks order of path as well? Also found some of the paths missing from dcc32.cfg and I think adding them back can solve my problem.
The order of the directories in a search path does matter if the file being searched for is found in more than one of the directories. For example, consider this search path:
dir1;dir2
If the file being searched for is in both dir1 and dir2, then the version found in dir1 will be used, because it is found first.
On the other hand, if the search path was:
dir2;dir1
then the version in dir2 would be used.
So, you can modify the order, but it changes the meaning of the search. Whether this has material affect for you, only you can know.
And yes you can add more directories to the paths, which also changes the meaning. Again, only you can know whether or not changes you make are appropriate.
Related
please take a look at the bin-win target in my repository here:
https://github.com/thinlizzy/bazelexample/blob/master/demo/BUILD#L28
it seems to be properly packing the executable inside a file named bin-win.tar.gz, but I still have some questions:
1- in my machine, the file is being generated at this directory:
C:\Users\John\AppData\Local\Temp_bazel_John\aS4O8v3V\execroot__main__\bazel-out\x64_windows-fastbuild\bin\demo
which makes finding the tar.gz file a cumbersome task.
The question is how can I make my bin-win target to move the file from there to a "better location"? (perhaps defined by an environment variable or a cmd line parameter/flag)
2- how can I include more files with my executable? My actual use case is I want to supply data files and some DLLs together with the executable. Should I use a filegroup() rule and refer its name in the "srcs" attribute as well?
2a- for the DLLs, is there a way to make a filegroup() rule to interpret environment variables? (e.g: the directories of the DLLs)
Thanks!
Look for the bazel-bin and bazel-genfiles directories in your workspace. These are actually junctions (directory symlinks) that Bazel updates after every build. If you bazel build //:demo, you can access its output as bazel-bin\demo.
(a) You can also set TMP and TEMP in your environment to point to e.g. c:\tmp. Bazel will pick those up instead of C:\Users\John\AppData\Local\Temp, so the full path for the output directory (that bazel-bin points to) will be c:\tmp\aS4O8v3V\execroot\__main__\bazel-out\x64_windows-fastbuild\bin.
(b) Or you can pass the --output_user_root startup flag, e.g. bazel--output_user_root=c:\tmp build //:demo. That will have the same effect as (a).
There's currently no way to get rid of the _bazel_John\aS4O8v3V\execroot part of the path.
Yes, I think you need to put those files in pkg_tar.srcs. Whether you use a filegroup() rule is irrelevant; filegroup just lets you group files together, so you can refer to the group by name, which is useful when you need to refer to the same files in multiple rules.
2.a. I don't think so.
I'm working on a custom rule in skylark that is trying to use the proto compiler. Due to intricacies of how it works, I need to split a path into a directory for the external dependency and the path part that is relative to that.
Example1:
File:[/private/var/tmp/_bazel_endobson/c56b77af296477cd0f319aa9d4ce1d19[source]]external/googleapis/google/devtools/build/v1/build_status.proto
I want the paths:
/private/var/tmp/_bazel_endobson/c56b77af296477cd0f319aa9d4ce1d19/external/googleapis/
google/devtools/build/v1/build_status.proto
Example2:
File:[[/private/var/tmp/_bazel_endobson/c56b77af296477cd0f319aa9d4ce1d19/execroot/bes_example]bazel-out/darwin_x86_64-fastbuild/genfiles]external/com_google_protobuf/google/protobuf/any.proto
I want the paths:
/private/var/tmp/_bazel_endobson/c56b77af296477cd0f319aa9d4ce1d19/execroot/bes_example/bazel-out/darwin_x86_64-fastbuild/genfiles/external/com_google_protobuf
google/protobuf/any.proto
The issue is that bazel allows accessing the root and root relative parts of the path, but doesn't give insight into if the path has the 'external/' part or not. The protocol buffer compiler needs this because it needs to know the directories that correspond to the root directories from the user's point of view so that it can use relative paths from the source.
Is there a principled way of detecting this other than hackily looking at the path to see if it has 'external' in it?
I'm afraid I cannot give you a really great answer here :( Eventually, we'd like to remove the "external" path segment, but it hasn't happened yet. The current rule is that you have it for source artifacts, but you don't have it for generated artifacts.
Thus, what I'd do is exactly what you suggest -- check if the first path segment is "external".
Metalsmith's documentation does not explain much about the path() function: #path(paths...): Resolve any amount of paths... relative to the working directory. This is useful for plugins who want to read extra assets from another directory, for example ./templates. That's it. That's the sum total of the documentation.
What arguments are expected and what do they do?
What I want to do is: Process different source directories according to different Metalsmith plugins. This seems to require me to create multiple templates/ directories under the separate source directories. If I want metalsmith-templates to look for templates under ../templates rather than ./templates, I would assume path() can do that... but in the absence of any meaningful documentation, I have no way to anticipate how to do it, or even whether it will work at all (short of reading the source code).
Answering my own questions:
path() is meant to be used in plug-in code, not the metalsmith project's index.js.
It takes a series of strings, which will be concatenated (with path separators) into a single path, which is then resolved relative to the metalsmith instance's given path.
E.g., from metalsmith-layouts:
var str = metalsmith.path(dir, data.layout || def);
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 file that describes input data, which is split into several other files. In my descriptor file, I first give the path A that tells where all the other files are found.
The originator may set either a relative (to location of the descriptor file) or absolute path.
When my program is called, the user gives the name of the descriptor file. It may not be in the current working directory, so the filename B given may also contain directories.
For my program to always find the input files at the right places, I need to combine this information. If the path A given is absolute, I need to just that one. If it is relative, I need to concatenate it to the path B (i.e. directory portion of the filename).
I thought boost::filesystem::complete may do the job for me. Unfortunately, it seems it is not. I also did not understand how to test wether a path given is absolute or not.
Any ideas?
Actually I was quite misguided first but now found the solution myself. When "base" holds the path A, and filename holds B:
boost::filesystem::path basepath(base), filepath(filename);
if (!basepath.is_complete())
basepath = filepath.remove_leaf() /= basepath;
base = basepath.string();
It works with Linux at least (where it would be very easy to do without boost, but oh well..), still have to test with Windows.