I have a patch file that needs to be applied in the working directory of codebase checked out using SVN. I need to write program to do this. Now I used SVNKIT jar to do (checkout from repository, updating code base, reverting any local changes). Now I could not figure out a way to apply a patch to the code base. Is there any way to do?
With SVNKit, use the "doPatch(java.io.File, java.io.File, boolean, int)" method of the SVNDiffClient class:
Arguments:
the source patch file
the target directory
"dryRun" - if "true", the patching process is carried out, and full notification feedback is provided, but the working copy is not modified
"stripCount" - specifies how many leading path components should be stripped from paths obtained from the patch (usually "0")
Related
Where is the following syntax used in a feature configuration (.prf) file? defined:
$$[QT_HOST_DATA/get]
I know $$[ ... ] is to access QMake properties as explained in the Qt doc, but where is the /get part of the notation in $$[QT_HOST_DATA/get] clarified? And what does it precisely do?
Also, inside a Qt .conf file, what is the difference between include (for other .conf files) and load() (for .prf files)?
If include(some.conf) merely consists in the contents of some.conf to be literally pasted into the including .conf file, what does load() do exactly?
I have found no info about the structure of .prf files.
https://doc.qt.io/qt-5/qmake-advanced-usage.html says that you can create .prf files, but says nothing about how these files are processed or should be structured?
Thanks for any clarifications you can provide!
where is the /get part of the notation in $$[QT_HOST_DATA/get] clarified? And what does it precisely do?
Nowhere, except qmake source code. It looks like all qmake properties may have upto four special "subproperies": xxx/dev xxx/src xxx/raw xxx/get. However, what are they used for is a mystery. Executing qmake -query QT_HOST_DATA/get produces (on my machine) just the same value as plain $$[QT_HOST_DATA].
I have found no info about the structure of .prf files.
Basically, .prf is just "system include file". There are two points, though:
All .prf files reside in a known location(s) pointed by QMAKEFEATURES variable.
BTW. QMAKEFEATURES is a sort of "protected variable". I managed to change it only with the help of (another undocumented) cache() function:
QMAKEFEATURES *= mydir # '*=' because of 3 passes under Windows
# 'transient' prevents creation file on disk
# only 'super' seems to work OK; no idea what's wrong with 'stash' or 'cache'
cache(QMAKEFEATURES, set transient super)
# now I can load .prf from <mydir> too...
Prf can be implicitly loaded by mentioning it in CONFIG variable. For example, CONFIG += qt (which is the default, btw.) results in include of <SomePrefix>/share/qt5/mkspecs/features/qt.prf Note that this takes place after the whole .pro was processed, so .prf file can be used to post-process user options.
what does load() do exactly?
It's just the version of include() designed specially for .prf. All it does, it simply includes .prf file. But, unlike CONFIG += xxx, it does this immediately, and, unlike plain include(), you shouldn't specify path and extension.
I'm new to OCaml, but I'm trying to figure out the equivalent of __filename, __dirname from Node. That is, I need to build a path relative to the file containing the code in question.
For reference, I'm working through Ghuloum's IACC: http://ell.io/tt$ocameel
I'm building my first compiler, and I have an utterly-simplistic ‘runtime’ file (in C — temporarily) adjacent to the compiler's source-code. I need to be able to pass the path to this file, as an argument (or a pre-compiled version, I suppose) to gcc or my linker, to have it linked against my compiler's output when I invoke the linker/assembler tooling.
(This may be a stupid question — I'm at a bit of an unknown-unknown here, “how does a compiler get the runtime to the linker”, or something like that. Any commentary about idiomatic solutions to this is welcome, even if it's not a direct answer to the above question!)
If you're running the source file directly via ocaml myfile.ml, Sys.argv.(0) will give you the path to the source file and you can use Filename.dirname to get the directory from that.
If you first compile the source file into an executable and then run the executable, Sys.argv.(0) will give you the name of the executable. In that scenario it's impossible to get the location of the source code (especially if you consider that the person running the executable might not even have the source code on their system).
If you set up your project structure, so that your sources live in src/, your compiled binary in bin/ and the compiled stdlib in lib/, you could just use Filename.dirname Sys.argv.(0) ^ "../lib" as the library path for gcc. This will work whether you run ocaml src/mycompiler.ml, bin/mycompiler or just mycompiler after installing everything to /usr/ or /usr/local/.
I made changes to the people-finder.js script to change the sort order, and locally everything works well. To override the functionality, I used the following directory structure and Maven-based SDK to generate AMP file:
As I expected, locally everything works fine and I can see my changes:
Next, I deploy the AMP file on the remote server, as described here: Install the AMP file
And here I do not see my changes:
Directory /opt/alfresco-community/tomcat/webapps/share/components/people-finder also contains the scripts without changes.
And thus, sorting does not work as I need.
Additional information: I unpacked the AMP file and not found there branch /web/components/... Of course, people-finder.js and people-finder-min.js is not present there also.
What could be the reason?
All that was required is to add a parameter -force:
sudo java -jar bin/alfresco-mmt.jar install amps/some-customization-share-1.0-SNAPSHOT.amp tomcat/webapps/share.war -force
Thank you very much Sanjay Patel for your assistance!
These discussions can also be useful:
Client-side changes don't apply after deployment the AMP
Files inside src/main/amp/web folder aren't packaged inside the resulting amp file
Modifications of original client-side files are not picked up
I am working with sbt-thrift plugin 0.6 and SBT 0.12.
In my thrift files I have mentioned the namespace as below.
namespace java abc.xyz
//some
//thrift
//codes
But the generated files goes to
gen-java/abc/xyz
(gen-java prefix is added automatically). How can I change this into
abc/xyz
?
There is an -out <outdir> option which does exactly that. In your case, specify the current folder . as the outdir.
Note that, unlike with the automatically generated gen-* folders, the outdir directory must exist. In other words, you have to make sure the folder is created before calling the Thrift compiler.
The --help option gives more information about all the other switches.
Regarding SBT, if the information on https://github.com/bigtoast/sbt-thrift is true, then you should contact the author of that software to add the option thriftJavaOutputDir as it seems missing.
BTW, the question looks very much like a duplicate of How to change default settings of sbt-thrift plugin in SBT? I would recommend to NOT ask ten thousand copies of similar questions on SO.
I added a simple JavaScript test to /src/chrome/test/data/webui/ and included the file in /src/chrome/chrome_tests.gypi.
I built it like this: ninja -C out/Debug browser_tests. That takes a while though. Is there a way to rebuild my test only, without also building all the other browser tests?
browser_tests is the only executable target to compile those tests so you need to use it in any case even if you perform a change in a single test. But you may want to try shared library compilation to improve the speed of your builds. For that just export GYP_DEFINES='component=shared_library' and then ./build/gyp_chromium before recompiling.
NOTE: This answer is not applicable to webui tests (they do not depend on test_data_dir_. Further, it is only relevant to Linux.
Some test files is not compiled into browser_tests. For these cases, just set the CR_SOURCE_ROOT environment variable to the Chromium source directory, e.g. (if your Chromium source files are located at ~/chromium/src)
CR_SOURCE_ROOT=~/chromium/src/ ./out/Debug/browser_tests
I discovered this when I tried to figure out why the extension tests did not run. I started with looking up the error message in the source code:
Extension error: Could not load extension from ''. Manifest file is missing or unreadable.
After some debugging with gdb, I found that the test extension that is supposed to be loaded by ExtensionBrowserTest::LoadExtensionWithFlags did not load because the path was invalid. path was somehow set to "extensions/api_test/webrequest", and because this is not an absolute path, it was cleared in UnpackedInstaller::GetAbsolutePath by extension_path_ = base::MakeAbsoluteFilePath(extension_path_);.
Consequently, Chromium tries to load an extension from location "" (empty string), which obviously fails.
Ultimately, I tracked down the cause to test_data_dir_, which is initialized at DIR_TEST_DATA, which in turn is derived from DIR_SOURCE_ROOT, which in turn is read from the CR_SOURCE_ROOT environment variable. With the following command, my tests ran again, and I was able to update the extension tests without recompiling.
CR_SOURCE_ROOT=~/chromium/src/ ./out/Debug/browser_tests