I've compiled PGO-instrumented build from A/src and collected the profile. Now I want to apply this profile when building from B/src. Is this possible? GCC complains about the lack of profile since absolute paths are different, but otherwise the code is exactly the same.
See the docs on -fprofile-prefix-path:
-fprofile-prefix-path=path
This option can be used in combination with profile-generate=profile_dir and profile-use=profile_dir to inform GCC where is the base directory of built source tree. By default profile_dir will contain files with mangled absolute paths of all object files in the built project. This is not desirable when directory used to build the instrumented binary differs from the directory used to build the binary optimized with profile feedback because the profile data will not be found during the optimized build. In such setups -fprofile-prefix-path=path with path pointing to the base directory of the build can be used to strip the irrelevant part of the path and keep all file names relative to the main build directory.
So when building from A/, set the prefix path to A/, and likewise for B/.
Related
I have a mono-repository ("monorepo") that contains the C++ source code for my application, as well as a tree of OE/Yocto files and directories that form the bitbake recipes required to build my final image.
I wish to build and install my application into the image, but as far as I can tell, the Yocto philosophy is that source code is "fetched" (e.g. via git), from an external place, before it is built. But in my case the source code resides in the same repository. It doesn't seem to make sense to me that the entire repository is downloaded again, by bitbake, just to fetch the source for this application, so I'm looking for a better way.
I'm familiar with the idea of putting all the source in the files/ subdirectory, alongside the recipe itself. The issue I have with that is that I don't want to keep the source in the Yocto layer's recipe tree. It can be built with the SDK, for example, or even with other completely unrelated toolchains, so it should not be buried within a Yocto layer. It has its own life, outside Yocto.
I'm also familiar with the EXTERNALSRC directive, that can be used to "point" to the source code with a relative path from the build directory. For example:
EXTERNALSRC = "${TOPDIR}/../../src/myproject"
However, this is frequently not recommended as a "production" mechanism due to path issues, and it also disables devtool:
ERROR: externalsrc is currently enabled for the myproject recipe. This prevents the normal do_patch task from working. You will need to disable this first.
So I'm looking for a recommendation on how to handle compiling an application that resides in the same repository as the recipe, without putting it in files/.
EDIT: I tried something along these lines:
SRC_URI = "file://${TOPDIR}/../../src/myproject/main.c \
file://${TOPDIR}/../../src/myproject/Makefile \
"
This did not compile, but with devtool modify myproject I was able to see that it has in fact copied the source into the build directory. The problem is that it's replicated the entire directory structure from the root all the way up to the original source directory, so my source is now sitting in a location like this:
/home/david/monorepo/yocto/build/workspace/sources/myproject/home/david/monorepo/src/myproject
do_compile will need to determine and set that working directory before it will compile.
This means that the path will change depending on the user and the location of where they've checked out the monorepo. This almost works, but doesn't seem usable as-is. Is there a way to modify where bitbake's "file" fetcher puts the source when given an absolute path?
EDIT 2:
I may have found a way that works with bitbake and devtool:
FILESEXTRAPATHS_prepend := "${TOPDIR}/../../src/myproject:"
SRC_URI = "file://main.c \
file://Makefile \
"
This seems to set up the devtool directory in a much saner way (no replication of the directory tree, just symlinks to the files in oe-local-files/* directory), and the bitbake recipe also builds and installs correctly.
Is this the right way to do it?
EDIT 3: Perhaps not, as FILESEXTRAPATHS is only intended to be modified by .bbappend recipes, not base .bb recipes - any comment on that?
Best practices dictate that you accomplish this by using FILESEXTRAPATHS from within a .bbappend file [source].
EDIT 4: PierreOlivier suggests using a relative symlink in the files/ directory to the application's source directory, so that SRC_URI can find the source as if it was actually present in files/. From what I can tell with my own experiments, this does seem to work, and devtool works with this also.
Are there any implications of this approach that I should be aware of?
Since cmake 3.9 the following generator expression has been introduced:
$<TARGET_BUNDLE_DIR:tgt>
For which the documentation states that:
Full path to the bundle directory (my.app, my.framework, or my.bundle) where tgt is the name of a target.
How can one obtain the same result (path to the bundle directory) if using cmake < 3.9?
I tried the following:
include(BundleUtilities)
get_dotapp_dir($<TARGET_FILE:my_target> DOTAPP_DIR)
Unfortunately it doesn't work. The documentation for get_dotapp_dir says:
Returns the nearest parent dir whose name ends with ”.app” given the full path to an executable. If there is no such parent dir, then simply return the dir containing the executable.
And the dir containing the executable is exactly what I'm getting out of it, even if a parent .app dir actually exists.
Unfortunately, $<TARGET_FILE:my_target> is a generator expression. According to the documentation, it is evaluated at build time (not at CMake generation time). See the related doc (emphasis is mine):
Generator expressions are evaluated during build system generation to
produce information specific to each build configuration.
Generator expressions are allowed in the context of many target
properties, such as LINK_LIBRARIES, INCLUDE_DIRECTORIES,
COMPILE_DEFINITIONS and others. They may also be used when using
commands to populate those properties, such as
target_link_libraries(), target_include_directories(),
target_compile_definitions() and others.
In other words, you cannot use $<TARGET_FILE:my_target> as argument to get_dotapp_dir. You have to pass a variable containing the full path of your executable.
Since CMake 3, the full path of generated target is impossible to retrieve without this generator expression. See CMP0026 for more info.
So as long as you keep this Policy set to its default value, you will not be able to compute the full path to your executable or the parent bundle.
You are not the first trying to solve this issue. But depending on "what to do with this bundle path", you may try the following solutions:
Set CMP0026 to OLD, and use LOCATION property to get the path to your executable, and the give this path to get_dotapp_dir to retrieve the corresponding bundle path. This solution is definitely not portable, may stop to work in the future, and is not advised...
If you need to access to your bundle path from a custom command or a custom target (at build time), you may use a script (python, php, bash, perl, etc.) to compute the path to bundle from the path to executable.
Currently, we use something like this in some project:
add_custom_command(TARGET MyTarget POST_BUILD
COMMAND ${PYTHON_EXECUTABLE} -u MakeRelease.py $<TARGET_FILE:MyTarget>
)
Unfortunately, there is no clean way to retrieve the bundle path at configuration time at the moment...
I'm trying to build a pre-existing HaxePunk project in sublime (switching away from FlashDevelop).
problem: Error: Could not process argument
Here's my .hxml file:
-neko
-cp "c:/path/to/project/src"
-main Main
I've read somewhere that you shouldn't use the /src convention for your src files. That's annoying, since I want assets and binaries in their own directories separate from src files. How do I properly configure this?
You really should use the the src convention and not stuff everything within the same directory. You also don't want to make the build specific to your machine, so in you example above you don't want an absolute path but a relative one. So try the following:
#content of c:/path/to/project/build.hxml
-neko bin/output.n
-cp src
-main Main
Note that for -cp you use the relative path. The path is relative to where haxe is executed. That usually coincides with where your build.hxml file is, but it is not mandatory.
Also, you didn't specify an output file for neko. Note that you will have to create the directory bin by hand because the compiler will not do that for you and will complain if it doesn't exist.
These information are general and in no way tied with Sublime. Sublime should play just nice with these settings.
I am autotoolizing a library project, and this project has some example programs. I want the example programs to be distributed in the dist, but not installed.
Currently the demo programs are organized like thus:
src/*.cpp (library source)
include/*.h (library headers)
demos/demo.cpp (example program)
demos/RunDemo (script to run demo)
It is important that RunDemo be runnable after building the software, without requiring the "install" step.
So far I have been able to build the "demo" exectuable using a noinst_PROGRAMS target. However, after make in a VPATH build, the following is available:
build/src/.libs/libxxx.so (etc..)
build/demos/demo
As you can see, the RunDemo script needed to execute "demo" is not copied to the $(builddir). I have tried a few things, e.g., adding RunDemo to dist_noinst_SCRIPTS, as well as adding my own copy targets and trying to hook all.. no matter what I try, I always get the output,
$ make RunDemo
make: Nothing to be done for `../../../projects/demo/RunDemo'.
I seem to be unable to create a target in the builddir that says "if this file is not in the builddir, copy it from the srcdir."
Is this possible with automake?
You can make files accessible in the build tree after the ./configure step using the AC_CONFIG_LINKS macro (provided with autoconf) in your configure.ac script. It will create a symbolic link if possible, otherwise it will copy the file.
In your case it would look like
AC_CONFIG_LINKS([demos/RunDemo:demos/RunDemo])
From the autoconf manual:
Macro: AC_CONFIG_LINKS (dest:source..., [cmds], [init-cmds])
Make AC_OUTPUT link each of the existing files source to the
corresponding link name dest. Makes a symbolic link if possible,
otherwise a hard link if possible, otherwise a copy. The dest and
source names should be relative to the top level source or build
directory
Using dist_noinst_SCRIPTS is still necessary for the file to be distributed.
I'm using bison parser generator in my Xcode 4 project. I've written custom build rule for generating C++-source file from *.y grammar file:
/usr/local/bin/bison
--defines="${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}.hpp"
--output="${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}.cpp"
--verbose "${INPUT_FILE_PATH}"
As you can see, Xcode places generated files in $DERIVED_FILES_DIR folder. Now I need to export generated header file grammar.hpp with object files as library.
The problem is that Xcode doesn't allow export files, that aren't included in project.
The first solution, as it seems, is to create a group with absolute path set to $DERIVED_FILES_DIR. Well, it actually works until I change my build settings to build Release configuration, since $DERIVED_FILES_DIR is dependent on build settings.
The second solution is somehow set group path to literally variable, i.e.
path = $DERIVED_FILES_DIR
So far I've found two possible ways to do it: How to reference files with environment variables? and File references relative to DERIVED_FILE_DIR in Xcode. Either way doesn't work for me.
Maybe someone knows better way to add generated files to project?
Your best options are:
Generate the files in your SRCROOT
Generate the files in BUILT_PRODUCTS_DIR
These both have "Relative to..." options that should allow you to add the files to your project.
I ended up generating files in ${SRCROOT} directory with custom make build target using Makefile that handles regenerating derived files. I just added these generated files to project, and made all actual build target depend on this make target.