I'd like to be able to discover what targets waf thinks should be built given the current changes. Is there something similar to scons's dry-run discussed here?
Based on waflib/extras/clang_compilation_database.py my only idea so far is to override exec_command, but that seems hacky.
Related
I need to do some postprocessing with the output of Eclipse Help transformation. Nothing too fancy, just some folder arrangement, adding some extra files.
I made a plugin for this purpose, but I didn't find the right extension points for Eclipse help, so I've had to implement my ant targets with depend.preprocess.post and depend.preprocess.clean-temp.pre.
The result is obvious: my plugin is working, but messes up all other output type.
I think the best scenario for me would be an extension point right at the end of the Eclipse help pipeline. How can I achive something like that?
Currently using: DITA-OT 2.1
Thanks in advance!
As you can see by opening the "DITA-OT/plugins/org.dita.eclipsehelp/plugin.xml", the "org.dita.eclipsehelp" plugin defines 4 extension points that could be used by another plugin, two of them are XSLT, one is for adding extra parameters and one called "dita.map.eclipse.index.pre" is for registering an extra ANT target to be called before the indexing is done.
So I think you will probably need to directly edit the "org.dita.eclipsehelp" plugin or copy it entirely and make it your own, rename its id, its transformation type.
In our mono-repo we have a directory called wild_west, were people are allowed to submit any code they want without code review. It's great for one-off tests and experimentatal code that is still worth keeping checked into git.
Developers are not allowed to depend on anything from wild_west in the rest of the code-base.
Is there a way to enforce that with bazel?
The only way I can think of currently is to require that all targets under //wild_west must add visibility = ["//wild_west:__subpackages__"]. However, this would not prevent people from simply making targets public. I would ideally like to be able to apply some sort of "maximum visibility scope" for all targets under wild_west so they can't be visible outside of wild_west.
Is this possible?
Alternatively, maybe there is a robust way to add a check in our CI for this?
Thank you!
Relative to Build Definition Names, I have this setup of builds in Team Foundation Server
Family > Iteration (branch) > Application
I am trying to establish a uniform nomenclature for the build definitions, and since currently we have the concept on Folders in TFS vNext, I was looking for something like this:
Family Folder > Iteration Folder > Family.Iteration.Application
Where
Family is something like Office365
Iteration is something like Alfa1, 2017.1, etc
Application is something like word
In this example would look like
Office365 > Alfa1 > Office365.Alfa1.Word
What do you guys think of this? What are the best practices in naming builds? How would you do it?
Thanks
Your naming conventions seem kind of strange to me, though I doubt that is to any fault of your own. Your application should look more like a version number. I.E 2.30.1.13 - or "Major.Minor.Revision.Build". This makes sorting much easier. Major and minor kind of change at the discretion of management. Revision changes when there is a bug fix and the build just increments with every build you run. Your iteration folder I would keep as just "Major.Minor" and the next folder would be "Major.Minor.Revision.Build" although this kind of depends on naming conventions you currently use.
originally, I use gradle to build my android project, but recently, I migrate it to bazel, and I find that bazel is truly fast than gradle, so I want to know why, but the doc of bazel doesn't give much idea about this, can anyone help me？
Thanks very much!
Full disclosure: I work on Bazel.
That's not an easy question to answer for two reasons. First, performance is highly dependent on the scenario. For example, we'd generally expect a clean build to be slower than a build where only a single file has changed. Second, I don't know how Gradle works internally, and they've done a lot of work recently to improve Gradle performance.
But I can talk about Bazel and what we're doing to make it fast. We've been working on build performance for ~10 years, starting long before we made it public.
The key feature is that we require all dependencies to be declared, and we track them explicitly. If you use a header file in C++, or depend on a Java library, you must declare this dependency in your BUILD file (and we enforce that these are declared by sandboxing individual actions). There are three effects from this:
First, we can heavily parallelize the build, because we know which things depend on which other things.
Second, we can make incremental builds very fast, because we can tell what parts of the build have to be re-done when you change a specific file (BUILD file, header file, source file, ...).
Third, we almost never have to do clean builds. Other build tools often require 'make clean' to get into a predictable state - since Bazel knows all the dependencies, it can get to a predictable state on every single build.
Another effect is that we can cache remotely (i.e., across users), and even execute on another machine, although neither of these are fully supported at the time of this writing.
I have been working with Pex(IntelliTests) for some time now and I wondered if it is possible to create the tests via some sort of command(or .exe) and not through the IDE(VS2015) with right-clicking the function.
I have an automated process which builds my projects and further runs my tests. However if the IntelliTests are not generated anew for the new implementation they are rather useless.
This may seem like a basic question but unfortunately I could not find any information on the internet.
A command line for IntelliTest is not yet supported. If you would like to see it supported, kindly add your vote here: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/8623015-enable-intellitest-to-run-in-the-build-pipeline