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
Related
I am trying to get my head around programming with multiple modules (in different files). I don't want to load explicitly the files with ìnclude in the right order.
I am using the Atom IDE as my development platform, so I don't run julia explicitly.
when I am just using importall Datastructures (where ModuleName is the name of the module) julia complains:
LoadError: ArgumentError: Module Datastructures not found in current path.
Run `Pkg.add("Datastructures")` to install the Datastructures package.
while loading F:\dev\ai\Interpreter.jl, in expression starting on line 8
There are two ways to build a package or module in julia:
1) Use the tools in PkgDev. You can get them with Pkg.add("PkgDev") ; using PkgDev. Now you can use PkgDev.generate("MyPackageName", "MIT") (or whatever license you prefer) to build your package folder. By default, julia will build this folder in the same directory as all your other external packages. On Linux, this would ~/.julia/v0.6/ (or whatever version you are running). Also by default, this folder will be on the julia path, so you can just type using MyPackageName at the REPL to load it.
Note that julia essentially loads the package by looking for the file ~/.julia/v0.6/MyPackageName/src/MyPackageName.jl and then running it. If your module consists of multiple files, you should have all of them in the ~/.julia/v0.6/MyPackageName/src/ directory, and then have a line of code in the MyPackageName.jl file that says include("MyOtherFileOfCode.jl").
2) If you don't want to keep your package in ~/.julia/v0.6/ for some reason, or you don't want to build your package using PkgDev.generate(), you can of course just set the files up yourself.
Let's assume you want MyPackageName to be stored in the ~/MyCode directory. First, create the directory ~/MyCode/MyPackageName/. Within this directory, I strongly recommend using the same structure that julia and github use, i.e. store all your code in a directory called ~/MyCode/MyPackageName/src/.
At a minimum, you will need a file in this directory called ~/MyCode/MyPackageName/src/MyPackageName.jl (just like in the method above). This file should begin with module MyPackageName and finish with end. Then, put whatever you want in-between (including include calls to other files in the src directory if you wish).
The final step is to make sure that julia can find MyPackageName. To do this, you will need ~/MyCode to be on the julia path. To do this, use: push!(LOAD_PATH, "~/MyCode") or push!(LOAD_PATH, "~/MyCode/MyPackageName").
Maybe you don't want to have to run this command every time you want to access MyPackageName. No problem, you just need to add this line to your .juliarc.jl file, which is automatically run every time you start julia. On Linux, your .juliarc.jl file should be in your home directory, i.e. ~/.juliarc.jl. If it isn't there, you can just create it and put whatever code you want in there. If you're on a different OS, you'll have to google where to put your .juliarc.jl.
This answer turned out longer than I planned...
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 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")
I'm converting a premake4 config to premake5. My prebuildcommands are failing because the commands are executed from the root working directory, not the directory that the premake5.lua is in that contains the 'prebuildcommands'. premake4 executed them in the subdirectory containing the prebuildcommands call.
Is this the new intended behavior? If so, it's not documented anywhere that I can find. I don't mind correcting the paths as long as it's not an bug.
This looks like the correct behavior to me. Premake doesn't attempt to parse the commands to identify paths, so they are left intact as entered. The command itself is executed by the build tool (Visual Studio, GMake, etc.) and so will operate in whatever directory the tool makes current at that time.
If I'm reading it right, you would like the command to execute in the project directory, so what about:
prebuildcommands {
"%{prj.location}/styx/utils/ndate > %{prj.location}/include/kerndate.h"
}
For Visual Studio, Premake will convert those tokens to $(ProjectDir) so they will stay relative to the generated project file.
I have a solution with various projects, one of which is the main executable, and the rest are libraries the executable depends on. Each one compiles and links fine. However, trying to start the executable gives weird results. Using ldd, I see that the executable is trying to find libraries like so:
../bin/debug/libBlahBlah.so => not found
However, for each project, I'm declaring "bin/debug" (which is the output directory for these libraries) as a libdirs entry, and linking against the library by adding "BlahBlah" as a link, where "BlahBlah" is the name of the project.
I'm not even sure how to accomplish this without premake. Any help is appreciated.
The original intention was to have the library sit next to the executable then set an RPATH that searched for the library next to executable. With the way it is now, it searches for that absolute path relative to the executable... I cannot figure out how to get it off.
I'm using premake5. I've tried to use the nightly and compiling myself. Upstream is currently not compiling however.
If you are using the latest alpha or source of Premake5, you can use the "RelativeLinks" flag to use -L/-l instead of relative paths to libraries:
project "MyProject"
flags "RelativeLinks"
You will still need to set up the rpath properly though; you can do that with buildoptions() and the appropriate command line flags for your compiler. Maybe (untested):
buildoptions "-Wl,-rpath=."
That should work in Premake 4 as well.