I've written an example:
git clone git#github.com:rynz/test-app.git
bazel test //...
It will error, complaining that com_google_absl could not be resolved.
Edit WORKSPACE and uncomment com_google_absl dependency, now it will build and test successfully.
rynz_app only depends on rynz_protocol, however, rynz_protocol also depends on com_google_absl. Why do I have to redeclare com_google_absl within rynz_app WORKSPACE when it is already declared in rynz_protocol WORKSPACE?
Kind regards,
Ryan
From the documentation:
Bazel only reads dependencies listed in your WORKSPACE file. If your
project (A) depends on another project (B) which list a dependency on
a third project (C) in its WORKSPACE file, you’ll have to add both B
and C to your project’s WORKSPACE file. This requirement can balloon
the WORKSPACE file size, but hopefully limits the chances of having
one library include C at version 1.0 and another include C at 2.0.
https://docs.bazel.build/versions/master/external.html#transitive-dependencies
Related
In its C++ unit testing tutorial, Bazel suggests adding a root level gtest.BUILD file to the workspace root in order to properly integrate Google Test into the test project.
https://docs.bazel.build/versions/master/cpp-use-cases.html
Why would one create a new BUILD file and add gtest prefix to it rather than adding a new build rule to an existing BUILD file in the workspace? Is it just a minor style preference?
Because if you added a BUILD file somewhere in the workspace (e.g. under //third_party/gtest/BUILD) then that file would create a package there.
Then, if you had targets declared in that BUILD file, would their files exist under //third_party/gtest, or would they exist in the zip file that the http_archive downloads? If the former, then there's no need for a http_archive because the files are already in the source tree; if the latter, then the BUILD file references non-existent files in its own package. Both scenarios are flawed.
Better to call gtest's BUILD-file-to-be something that doesn't create a package, but that's descriptive of its purpose.
The build_file attribute of http_archive can reference any file, there's no requirement of the name. The name gtest.BUILD is mostly stylistic, yes, but it also avoids creating a package where it shouldn't. You could say it's an "inactive" BUILD file that will be "active" when Bazel downloads the http_archive, extracts it somewhere, and creates in that directory a symlink called BUILD which points to gtest.BUILD.
Another advantage of having such "inactive" BUILD files is that you can have multiple of them within one package, for multiple http_archives.
For some reasons, practical or not, rxjs npm package stores BAZEL.build configuration in the package, so when I'm trying to build my project (which has node_modules folder) bazel tries automatically to build something that it's not supposed to build at all.
My question would be - what is canonical way of ignoring some specific folder while building bazel project recursively?
The only way to achieve what I'm looking for that I know of is to point to it explicitly in the command line
bazel build //... --deleted_packages=node_modules/rxjs/src (see user manual)
But I don't want to type this every time.
Bazel recently added a feature for ignoring folders (similar to gitignore).
Simply add node_modules to the .bazelignore file in the root of your project.
Yes, this is expressible as a bazel target pattern:
bazel build -- //... -//node_modules/rxjs/src/...
Full documentation is available at https://docs.bazel.build/versions/master/user-manual.html#target-patterns
How to create build definition for multiple solutions that have dependency?
Background here:
There are two solutions
Solution A is class library contains an object class 'ClassA'
Solution B is console program that use 'ClassA' by add dll reference generated by solution A.
I would like to server build both solutions using one TFS 2017 build definition.
It raise out error:
Main\Source\SolutionB\Program.cs (13, 13)
Main\Source\SolutionB\SolutionB\Program.cs(13,13): Error CS0246:
The type or namespace name 'SolutionA' could not be found (are you
missing a using directive or an assembly reference?)
How to config the build definition that SolutionB would know to use the dll generated from the build of SolutionA?
You should build your first project that will be used at second project as dll and than copy files to build artifacts; than publish your dlls to specific folder that you referenced in your second project and finally build your second project.
You can check this image that with similiar process, just in below image it is publishing artifacts to three diffrent location, in your case it should be one publish task.
This is one of the simple way; but if you use the project A for some other projects too you may want to use NuGet packages. I am going to describe this as solution 2.
Solution 2: You should create a Nuget packages by the artifacts of Project A. You can host your Nuget packages in custom source folder. Add your first project's package to your project as a reference. You don't need to do something extra just add a nuget restore task to your build definition. If you want, you can publish your first project as a nuget package during the build definiton. Please check how to restore and install neuget packages by build definiton.
I'm trying to build projects in project group from command line using MSBuild. After reading this page, my batch file looks like this:
SET BDS=C:\Program Files (x86)\Embarcadero\Studio\17.0
SET FrameworkDir=C:\Windows\Microsoft.NET\Framework
SET FrameworkVersion=v3.5
"%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild" .\Source\MyProjectGroup.groupproj /t:build /p:config=Debug /p:Platform=Win32 /verbosity:minimal /fileLogger /fileLoggerParameters:LogFile=Build.log;Verbosity=detailed;Append=true
Build fails, if I try to perform a "clean" build (that is, get source files from source control and run build from command line).
Looks like it tries to build projects in order they are placed in groupproj file. Consider this example:
there are two package projects, package A and package B;
package B requires package A;
package B is placed before package A in groupproj file.
In this case, "clean" build will fail, but if I reorder projects in project group, or build package A first, build will be successful.
E.g., MSBuild targets for C# resolve dependencies from project references.
But groupproj neither include dependencies info:
<Projects Include="NativePackages\Drawers\Drawers.dproj">
<Dependencies/>
</Projects>
nor processing DCC_Reference properties in dproj files:
<DCCReference Include="Drawers.dcp"/>
Am I doing something wrong?
Is there any option/property to trigger?
Could MSBuild targets for Delphi resolve dependencies automatically?
UPDATE
I know about "Dependencies..." context menu item in Project Manager (it just affects Dependencies tag in groupproj file).
I want to generate a P2 repository from OSGI bundles that reside on maven central.
I have
defined a POM-first feature project using dependencies=consider
defined Maven dependencies with scope compile and type jar
defined a feature.xml with exact references to the bundle symbolic names and versions as declared in their manifest.mf
When I attempt to build the feature, I receive
No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from org.codehaus.jackson.feature.group 1.9.1.qualifier to jackson-mapper-lgpl [1.9.12,1.9.13).", "Unable to satisfy dependency from org.codehaus.jackson.feature.group 1.9.1.qualifier to jackson-core-lgpl [1.9.12,1.9.13).", "No solution found because the problem is unsatisfiable."]
Where org.codehaus.jackson.feature is the feature I am building and jackson-mapper-lgpl [1.9.12,1.9.13) and jackson-core-lgpl [1.9.12,1.9.13) are the specifications of the OSGI bundles I am trying to include.
When I switch on debug mode, I see that the components are being found, which makes the behavior more odd:
[DEBUG] P2Resolver: artifact org.codehaus.jackson:jackson-core-lgpl:1.9.12 at location /home/jsuess/.m2/repository/org/codehaus/jackson/jackson-core-lgpl/1.9.12/jackson-core-lgpl-1.9.12.jar resolves installable unit jackson-core-lgpl/1.9.12
[DEBUG] P2resolver.addMavenArtifact org.codehaus.jackson:jackson-mapper-lgpl:jar:1.9.12:compile
[DEBUG] P2Resolver: artifact org.codehaus.jackson:jackson-mapper-lgpl:1.9.12 at location /home/jsuess/.m2/repository/org/codehaus/jackson/jackson-mapper-lgpl/1.9.12/jackson-mapper-lgpl-1.9.12.jar resolves installable unit jackson-mapper-lgpl/1.9.12
[DEBUG] Registered artifact repository org.eclipse.tycho.repository.registry.facade.RepositoryBlackboardKey(uri=file:/resolution-context-artifacts#/home/jsuess/workspace/org.codehaus.jackson/features/org.codehaus.jackson)
I believe taking bundles from maven and creating P2 must be a common use case, so I wonder if someone can point me to a working sample POM that I can use as a template.
Note that every module in a Tycho build has a separate target platform.
So if you are using pomDependencies=consider, but you only configure this switch and/or the dependencies on an eclipse-feature module, the POM dependencies will only be in the target platform of the module. If you then try to package the feature into an eclipse-repository, the dependency resolution of that module will fail because of missing (transitive) dependencies of the feature.
In most cases, you don't need different target platforms per module, so in general you should put all target platform configuration and POM dependencies into the parent POM.
If you have done this, but one of your modules still seems to have a different target platform, make sure that the parent POM reference of that module is correct - and that you don't reference an older version of your parent POM.