I built eng flavor of AOSP tree and installed on a device. I like to step through code of a module (say libinput.so). I want to build this module with "-O0 -g" passed as part of CFLAGS. BUT I don't want to change the Android.mk file of this module.
Lets say this module is at aosppath/frameworks/base/service/input.
I cd to this folder after sourcing build/envsetup.sh.
I tried "mm -B LOCAL_STRIP_MODULE=false". When I was stepping through eclipse gdb, I see the execution order going zig zag.
Then I tried "mm -B LOCAL_STRIP_MODULE=false LOCAL_CFLAGS="-O0 -g""
Now gdb was able to step through fine. But this doesn't seem to work in other projects. I have a module that uses skia and opengl. The build is failing when I pass LOCAL_CFLAGS on command line.
What is the suggested way to make debug flavor of specific .so or exe under AOSP tree?
Thanks
So since the main reason you don't want to make changes to Android.mk is so you don't have to check it in, an alternative here is to use the .repo/local_manifests folder to change a module that is owned by android to be owned by you.
Here is a sample my_manifest.xml file which can do this for you:
<manifest>
<remote name="origin"
fetch="ssh://git#github.com/YourRepoHere/" />
<remove-project name="platform/frameworks/base"/>
<project path="frameworks/base" remote="origin" name="frameworks-base" revision="your-branch-name"/>
</manifest>
This will remove frameworks/base from the android manifest tree, and replace it with your own manifest tree (which you need to fork into your own repository).
After that, you can then use a conditional inside of your Android.mk file like so:
ifeq ($(TARGET_BUILD_VARIANT),userdebug)
CONDITIONAL_CHANGES_HERE
endif
Again, I realize that you didn't want to modify the Android.mk file but since you also asked for the suggested way of making a module that is conditional on the build variant, I am going to include this answer anyway in case nothing better comes your way. This is really the suggested way of doing what you want to do, as your project will now be maintained by the repo tool.
Related
I'm trying to use add_custom_command to generate a file during the build. The command never seemed to be run, so I made this test file.
cmake_minimum_required( VERSION 2.6 )
add_custom_command(
OUTPUT hello.txt
COMMAND touch hello.txt
DEPENDS hello.txt
)
I tried running:
cmake .
make
And hello.txt was not generated. What have I done wrong?
The add_custom_target(run ALL ... solution will work for simple cases when you only have one target you're building, but breaks down when you have multiple top level targets, e.g. app and tests.
I ran into this same problem when I was trying to package up some test data files into an object file so my unit tests wouldn't depend on anything external. I solved it using add_custom_command and some additional dependency magic with set_property.
add_custom_command(
OUTPUT testData.cpp
COMMAND reswrap
ARGS testData.src > testData.cpp
DEPENDS testData.src
)
set_property(SOURCE unit-tests.cpp APPEND PROPERTY OBJECT_DEPENDS testData.cpp)
add_executable(app main.cpp)
add_executable(tests unit-tests.cpp)
So now testData.cpp will generated before unit-tests.cpp is compiled, and any time testData.src changes. If the command you're calling is really slow you get the added bonus that when you build just the app target you won't have to wait around for that command (which only the tests executable needs) to finish.
It's not shown above, but careful application of ${PROJECT_BINARY_DIR}, ${PROJECT_SOURCE_DIR} and include_directories() will keep your source tree clean of generated files.
Add the following:
add_custom_target(run ALL
DEPENDS hello.txt)
If you're familiar with makefiles, this means:
all: run
run: hello.txt
The problem with two existing answers is that they either make the dependency global (add_custom_target(name ALL ...)), or they assign it to a specific, single file (set_property(...)) which gets obnoxious if you have many files that need it as a dependency. Instead what we want is a target that we can make a dependency of another target.
The way to do this is to use add_custom_command to define the rule, and then add_custom_target to define a new target based on that rule. Then you can add that target as a dependency of another target via add_dependencies.
# this defines the build rule for some_file
add_custom_command(
OUTPUT some_file
COMMAND ...
)
# create a target that includes some_file, this gives us a name that we can use later
add_custom_target(
some_target
DEPENDS some_file
)
# then let's suppose we're creating a library
add_library(some_library some_other_file.c)
# we can add the target as a dependency, and it will affect only this library
add_dependencies(some_library some_target)
The advantages of this approach:
some_target is not a dependency for ALL, which means you only build it when it's required by a specific target. (Whereas add_custom_target(name ALL ...) would build it unconditionally for all targets.)
Because some_target is a dependency for the library as a whole, it will get built before all of the files in that library. That means that if there are many files in the library, we don't have to do set_property on every single one of them.
If we add DEPENDS to add_custom_command then it will only get rebuilt when its inputs change. (Compare this to the approach that uses add_custom_target(name ALL ...) where the command gets run on every build regardless of whether it needs to or not.)
For more information on why things work this way, see this blog post: https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
This question is pretty old, but even if I follow the suggested recommendations, it does not work for me (at least not every time).
I am using Android Studio and I need to call cMake to build C++ library. It works fine until I add the code to run my custom script (in fact, at the moment I try to run 'touch', as in the example above).
First of,
add_custom_command
does not work at all.
I tried
execute_process (
COMMAND touch hello.txt
)
it works, but not every time!
I tried to clean the project, remove the created file(s) manually, same thing.
Tried cMake versions:
3.10.2
3.18.1
3.22.1
when they work, they produce different results, depending on cMake version, one file or several. This is not that important as long as they work, but that's the issue.
Can somebody shed light on this mystery?
I need to build libpng, but without #define PNG_READ_eXIf_SUPPORTED in pnglibconf.h
I've read comments from pnglibconf.dfa, and here are some ways of disabling features, however I didn't manage to make what I want using them.
The problem is in that, build process is performed on build server, so I can't change any files inside of libpng submodule. Here is how server works:
Download clone sources from git
Generate makefile by running cmake ..
Run make command.
Thus I have libnpg, but with included PNG_READ_eXIf_SUPPORTED option.
Libpng is a submodule of my project, so it checked out by build server automatically so I can't change pnglibconf manually.
As it said in pnglibconf.dfa file:
There are three ways of disabling features, in no particular order:
1) Create 'pngusr.h', enter the required private build information
detailed below and #define PNG_NO_<option> for each option you
don't want in that file in that file. You can also turn on options
using PNG_<option>_SUPPORTED. When you have finished rerun
configure and rebuild pnglibconf.h file with -DPNG_USER_CONFIG:
make clean
CPPFLAGS='-DPNG_USER_CONFIG' ./configure
make pnglibconf.h
pngusr.h is only used during the creation of pnglibconf.h, but it
is safer to ensure that -DPNG_USER_CONFIG is specified throughout
the build by changing the CPPFLAGS passed to the initial ./configure
I tried to do what is written here. I run cmake .. -DCMAKE_C_FLAGS="-DPNG_USER_CONFIG -I/home/me/dev/include" where /home/me/dev/include - is a path to pngusr.h file
Then I run make command. However, PNG_READ_eXIf_SUPPORTED is still present in generated (by make command pnglibconf.h file).
So my main question is how to make libpng without PNG_READ_eXIf_SUPPORTED option?
It remains unclear to me whether and to what extent the specific customization mechanism you are trying to use works in the version of libpng you are trying to use. But it looks like there's a simpler way. Just below the excerpt you posted, in the same file, is the second (of three) alternatives:
2) Add definitions of the settings you want to change to CPPFLAGS;
for example:
-DPNG_DEFAULT_READ_MACROS=0
(lightly formatted). I'm not in a good position to test that on the CMake-based build system, but it seems to work like a charm in the Autotools build system. From examining and comparing the two, I think it will work for CMake, too. In particular, you would want to run
cmake .. -DCMAKE_CPP_FLAGS="-DPNG_NO_READ_eXIf"
for your particular case.
Note, by the way, that the CPP (i.e. preprocessor) flags are the right place for an option such as you are specifying (for -DPNG_USR_CONFIG in your original attempt, too). In practice, though, they probably still work in the C compiler flags.
I have SCons code in which I am using SConscripts to build different directories separately. In my Src directory, my SConscript builds a shared library, and then returns the resulting Node as the Python variable libMyLibrary. I typically use the install option to copy this library to a directory that is on my system's LD_LIBRARY_PATH (I'm using OpenSUSE).
So far, so good. Now, in another directory, Src/Test, another SConscript imports libMyLibrary and builds some Programs using code like this:
env.Program('myProgram', 'myProgram.cpp', LIBS=[env['LIBS'], libMyLibrary])
The program then gets installed to my local bin folder. This code does track the library dependency and build the program, but the problem is that since the library is in a sub-directory (Src), that sub-directory gets included in the linker command. Here is an abbreviated example of the linker command that SCons generates:
g++ -o Src/Test/myProgram Src/Test/myProgram.o Src/libMyLibrary.so
I believe this happens because the Node,libMyLibrary, is essentially a path. The problem is that when I try to run the program, it is not looking for libMyLibrary.so in my library folder, but rather Src/libMyLibrary.so, and of course it doesn't find it.
I do NOT want the libraries I build to be installed in sub-directories of my install folder.
I already add the Src folder to LIBPATH, so SCons adds the -LSrc option to the linker command, but that doesn't solve the problem. My preference would be that when I add a Node, the path should automatically get parsed out to add the appropriate -L and -l options.
I know that I can get around this problem by adding the string 'MyLibrary' to the LIBS variable instead of the libMyLibrary Node, but then I have to explicitly tell SCons that each Program Depends() on libMyLibrary. It seems very inefficient to short-circuit SCons's built-in dependency tracking this way. Does anyone know the correct, SCons-y way to do this?
I'm referring to your latest comment: It looks to me as if this is not really a SCons problem, but more a general linker question (XY problem). Are you perhaps simply searching for RPATH? Please also check this old SO question: scons executable + shared library in project directory
I wand to implement in CMake a functionality that would enable the installation of a single binary/target through a make install-TARGET command. This is fairly straightforward to do with a custom target. However, when the target binary in question is linked dynamically against other libs of the project (BUILD_SHARED_LIBS=ON), I need to install the receptive libs as well. Is there any way to somehow query the list of libraries?
I've looked at the target properties, but haven't found anything relevant.
Tips on how to get the list of libs and/or other ways to implement the above described functionality would be very much appreciated!
[Edit]
Example:
Let's assume that there the project MyProj has a CMake target "myprog" which generates the binary myprog. I want to install only this binary with make install-myprog. However myprog links against libmy1.so and the latter links against libmy2.so, both part of MyProj.
I need a mechanism to figure out that I need to install both libmy1.so and libmy2.so along myprog.
I don't do *nix development, but the functionality you're looking for is same as "Dependency Walker" for windows. A quick search brought up the following:
Dependency resolution in Linux
Hope it helps.
The most elegant solution seems to be the following. One has to use the CMake COMPONENT parameter of the install command to assign each install target to a component. For example in the question this would be something like this:
install(TARGETS myprog DESTINATION ${BIN_DEST_DIR} COMPONENT myprog),
and similarly for the shared libraries
install(TARGETS my1 my2 DESTINATION ${LIB_DEST_DIR} COMPONENT my-libs).
Now, to invoke the installation of myprog as well as mylib1 and mylib2 a custom target has to be created that uses the cmake_install.cmake locate in the build tree:
add_custom_target(install-myprog
COMMAND ${CMAKE_COMMAND} -DCOMPONENT=my-libs -P ${CMAKE_BINARY_DIR}/cmake_install.cmake
COMMAND ${CMAKE_COMMAND} -DCOMPONENT=myprog -P ${CMAKE_BINARY_DIR}/cmake_install.cmake
COMMENT "Installing myprog").
So I have scons working with an alternate build location (build/ for my output files, src/ for my input files) and it works great. Except for one thing.
I'm using an IDE (TI Code Composer 4) to debug my program. I point the IDE at the output executable to run it, and what it uses for the source files for debugging is the build/ directory. I don't really care, except when I go to edit the file in the IDE, for example main.cpp, the file is really build/main.cpp which gets clobbered as soon as I run scons again. I have to remember to edit src/main.cpp instead. I am aware of this issue and yet I make the same mistake often.
Is there a way to have scons make the source files it copies into the build path read-only? (I'd ask how to get TI CCS4 to use the right source files when it is debugging an executable, but I doubt I'd get any answers.)
This page has information about wrapping InstallTargets with a chmod call.
FYI, the scons user list is quite active with many knowledgeable people and you can get answers pretty quickly.
You could always tell scons not to duplicate source files in the build directory:
SConscript('src/SConscript', variant_dir='build', duplicate=0)