The top directory of AOSP is ~/WORKING_DIRECTORY. If I run
~/WORKING_DIRECTORY$ make
the whole system builds correctly.
According to Building a particular module in the android source code, https://stackoverflow.com/a/30671099/746461, if I need to rebuild art, I will
cd art
mm
However it throws error:
FAILED: out/target/common/cpplint/art__compiler__optimizing__nodes.h
/bin/bash -c "(art/tools/cpplint.py --quiet --root=. --filter=-whitespace/line_length,-build/include,-readability/function,-readability/streams,-readability/todo,-runtime/references,-runtime/sizeof,-runtime/threadsafe_fn,-runtime/printf art/compiler/optimizing/nodes.h ) && (mkdir -p out/target/common/cpplint/ ) && (touch out/target/common/cpplint/art__compiler__optimizing__nodes.h )"
art/compiler/optimizing/nodes.h:3974: Labels should always be indented at least one space. If this is a member-initializer list in a constructor or the base class list in a class definition, the colon should be on the following line. [whitespace/labels] [4]
art/compiler/optimizing/nodes.h:3978: Labels should always be indented at least one space. If this is a member-initializer list in a constructor or the base class list in a class definition, the colon should be on the following line. [whitespace/labels] [4]
art/compiler/optimizing/nodes.h:3983: Labels should always be indented at least one space. If this is a member-initializer list in a constructor or the base class list in a class definition, the colon should be on the following line. [whitespace/labels] [4]
art/compiler/optimizing/nodes.h:3987: Labels should always be indented at least one space. If this is a member-initializer list in a constructor or the base class list in a class definition, the colon should be on the following line. [whitespace/labels] [4]
art/compiler/optimizing/nodes.h:3992: Labels should always be indented at least one space. If this is a member-initializer list in a constructor or the base class list in a class definition, the colon should be on the following line. [whitespace/labels] [4]
art/compiler/optimizing/nodes.h:3996: Labels should always be indented at least one space. If this is a member-initializer list in a constructor or the base class list in a class definition, the colon should be on the following line. [whitespace/labels] [4]
Done processing art/compiler/optimizing/nodes.h
Total errors found: 6
[ 1% 108/10017] Building with Jack: out/ho...S/core-oj-hostdex_intermediates/classes.dex
ninja: build stopped: subcommand failed.
17:27:03 ninja failed with: exit status 1
#### failed to build some targets (13 seconds) ####
If I stay in ~/WORKING_DIRECTORY and call mm art, it seems to build correctly.
However, if I deliberately make a mistake in the source code, then run
~/WORKING_DIRECTORY$ mm art
it still builds, which means the new files are not compiled at all. See the screenshot.
What's the correct way of rebuilding a module?
Cleaning of module:
cd $ANDROID_BUILD_TOP
make clean-module_name
art project have more than one target modules. You should use clean for them one by one.
Related
I use swiftlint in my project. The project name is ABC xx and it works fine with swiftlint. Now I decided to include Unitest in my application and I have to import #testable import ABC_xx into the swift test file which is class ABC_xxTests: XCTestCase { not I get an error with Swiftlinter which says Type Name Violation: Type name should only contain alphanumeric characters: 'ABC_xxTests' (type_name) how do I sort this error
The following swiftlint rule enable the use of underscore in your Swift class names:
type_name:
allowed_symbols: "_"
EDIT:
If you want to enable the use of underscore also for variable names use:
identifier_name:
allowed_symbols: "_"
In addition to #carmine's answer, keep the below two things in mind while adding attributes to any rule in .swiftlint.yml:
it should be listed in a new line
and should be preceded with a white space.
In my case I overlooked the white space before allowed_symbols. So the linting was not working. When I added white space, it was successful.
You can disable rule for specified folder, in your case its an ABC_xxTests folder. Inside .swiftlint.yml configuration file you can use 'excluded' property. If you haven't yet create swiftlint configuration file, you can create one with name .swiftlint.yml and place it in your project root folder.
Add this lines:
excluded:
- ABC_xxTests
Use of underscore for variable names add in .swiftlint.yml:
variable_name:
allowed_symbols: "_"
So I have a script that takes an input and prints whatever. It needs access to a file written by a third party. My Xcode project structure is just two files, main.swift and ThirdParty.swift. If I just run it from Xcode main.swift happily sees ThirdParty.swift and I'm apply to instantiate an object defined within. When I run from the command line it cannot find ThirdParty.swift (which is pretty much to be expected; how would it know it's there?).
None of the command line options to pass to /usr/bin/swift seem to be appropriate for pointing to a file I'd like to use and pointing it to the current directory doesn't work either. Is this even possible or should I just give up?
The ideal end result is the ability to do something like:
./main.swift --option1 --option2 thing
But an acceptable place to end up would be:
swift -X ThirdParty.swift main.swift --option1 --option2 thing
Where X is whatever option I need to be passing in.
You can't pass two files into "immediate" mode (swift REPL mode) but you have several other options:
Combine the files together on the fly into a temporary file (with e.g. /bin/cat)
Compile the two files into a normal binary with swiftc.
I recommend option 2, though it means every time you change the code you'll need to recompile, and the binaries it creates aren't portable between OS X and Linux.
I have written some codes in R that I have compiled into a package. Unfortunately
I am not able to publish it as a package such that any user may download it with the
install_github() function.
Kindly help.
I have shared the path for the repository below.
https://github.com/Kagereki/RPerio
When I try to install your package I get the following error:
Error: Line starting 'Population-Based Sur ...' is malformed!
The specification for DESCRIPTION files states that
DESCRIPTION uses a simple file format called DCF, the Debian control format. You can see most of the structure in the simple example below. Each line consists of a field name and a value, separated by a colon. When values span multiple lines, they need to be indented:
Description: The description of a package is usually long,
spanning multiple lines. The second and subsequent lines
should be indented, usually with four spaces.
Inspecting your DESCRIPTION file shows that its Description field is indeed formatted incorrectly, with the second line not indented:
Description: A collection of tools for Case Definitions and prevalences in
Population-Based Surveillance of Periodontitis.
The functionality is experimental and functions are likely to ...
Note that this line begins with "Population-Based Sur ...", as suggested by the error message.
Make sure your DESCRIPTION is properly formatted and see if that fixes things.
You should be able to use the check() function from devtools to make sure that everything is working locally before you push up a new version.
I'm generating developer documentation using Doxygen. It's parsing all of the files correctly, but the output is generating duplicate entries in the member function list and class diagram.
Any ideas?
I had this exact problem, and found that I had accidentally specified a build folder in the INPUT line due to RECURSIVE being on, e.g.,
Example file structure:
./
MyLibrarySources/
Libs/
build/
Doxyfile:
INPUT = ./ MyLibrarySources/ ...
RECURSIVE = YES
This caused Doxygen to parse the headers from two different locations: once from MyLibrarySources/, and once from build/, producing duplicate members and other odd results.
The easy solution is to add your build directory to the EXCLUDE line, e.g.:
EXCLUDE = "build"
This makes Doxygen not parse the same header files in two different locations. And yes, in-source build directories are usually a bad idea, place them elsewhere. In my case, command-line builds not issued from my IDE went there by default.
Edit note: I had incorrectly believed that the source files were being parsed twice because of the double-specification in the INPUT line. This is not the case. Doxygen is smart about this and will not parse the same physical file twice 👍.
I'm having trouble correctly using the /GROUP="" command line parameter for my installation when called by a parent installation. What exactly should be specified and what is the "base"?
For example, the parent installer determines the full path to where the start menu entries will be. If this path is passed to /GROUP, it gives an error about invalid characters; namely, :.
I know the parameter supports use of expand prefix, but does this mean the parent installer must determine which constant to "expand" rather than simply passing the already determined path?
UPDATE:
It seems I was mistaken in thinking I could select the "base" of the menu entries (all users, local). It seems this is done automatically, but perhaps this is a more complete example:
An older Wise installation determines the filesystem path where the menu entries will be installed. It then executes my installation and passes that path using /GROUP. This is where my problem arises because /GROUP expects only a directory, not a full path.
The /GROUP="x" parameter specifies the value for the {groupname} constant, eg. it should be of the form /GROUP="MyApp". It should not contain a path, or at least if it does contain one it should be a very shallow relative path such as /GROUP="MyCompany\MyApp".
If you are passing the parameter from a parent Inno install script and you want the child install to install icons into the same group as the parent then you should use /GROUP="{groupname}".
In all cases, the "root" of the path will automatically be chosen by Inno to be either {commonprograms} or {userprograms} depending on the PrivilegesRequired setting of the install script being run.
Note that if you are running the installer as part of an automatic update to an already-installed application, you should not pass the parameter at all. Inno will remember the user's previous selection and use this by default; in fact it's strongly recommended to not offer the user a chance to change this during interactive upgrades by setting the following:
[Setup]
DisableDirPage=auto
DisableProgramGroupPage=auto