I have a CMake project (myapp) that depends on another CMake project (integrator). The integrator project is declared via the ExternalProject_Add and I use the GIT_TAG parameter to indicate what version of the integrator code to build. This works great while online. But, I run into build fail problems if I'm ever offline. It always fails the build if it can't reach the git repo, even if it had previously downloaded a copy of the repo. Can I make CMake stop reaching out to the GIT_TAG repo and just build with the code it had previously downloaded when I was last online?
Based on the documentation of ExternalProject, there is an option named UPDATE_DISCONNECTED.
If UPDATE_DISCONNECTED is set, the update step is not executed
automatically when building the main target. The update step can still
be added as a step target and called manually. This is useful if you
want to allow to build the project when you are disconnected from the
network (you might still need the network for the download step). This
is disabled by default.
Therefore, you should add the option setting
UPDATE_DISCONNECTED 1
to your ExternalProject_Add declaration in order to be able to work offline.
Related
In Meson, subprojects can be defined using wrap-files. The manual shows an example of a wrap-git file:
[wrap-git]
url = https://github.com/libfoobar/libfoobar.git
revision = head
I've set-up a local test project that sets up a subproject like the example above. All works well and Meson pulls in the subproject's repository, builds it, and links it with the test project executable.
However, when I push a new change to the subproject repository, Meson fails to pull in these changes automatically even though revision = head is specified in the wrap-file. To be clear, I did not really expect this to work.
What does work is manually removing the subproject's source code and then letting Meson reconfigure the project. This clones the subproject repository and thus pulls in updates. But sadly this is a manual action...
My question: when tracking the head revision in a git wrap-file of a subproject, how to pull updates automatically?
This is expected behavior. As per reference doc:
Once a subproject has been fetched, Meson will not update it
automatically. For example if the wrap file tracks a git branch, it
won't pull latest commits.
To pull latest version of all your subprojects at once, just run the
command:
$ meson subprojects update
If only selected are needed, add names after command:
$ meson subprojects update libfoo libbar
(this is in short, more details in the link)
I was trying to cross compile glib for arm. It has a dependency on libffi, but found that a meson build for libffi was last updated 2 yrs back and there is a problem with what is available.
Therefore i had to define a wrap file to take the latest source of libffi.
My first idea was to use a wrap file as below -
[wrap-git]
directory=libffi
url=https://github.com/libffi/libffi
revision=head
p.s its the head revision that has the right source code for libffi. But it needed a meson revision and doesn't seem to take the head.
Therefore i went for the [wrap-file] option,
[wrap-file]
directory = libffi-3.3
source_url = https://github.com/libffi/libffi/releases/download/v3.3/libffi-3.3.tar.gz
source_filename = libffi-3.3.tar.gz
source_hash = 72fba7922703ddfa7a028d513ac15a85c8d54c8d67f55fa5a4802885dc652056
But still i get this error "Subproject exists but has no meson.build file" when doing a meson build.
This is the original wrap file that came alongwith glib.
[wrap-git]
directory=libffi
url=https://github.com/centricular/libffi.git
revision=meson
what is the easiest way to get a wrap file working.
As far I can see, someone forked project and added support for meson, named that branch meson, so revision is just a name of branch containing meson.build
Official project does not have support for meson.build. What is really happening is when you build your project that uses wrap git/file, that project is fetched/downloaded&unzip and it searches for meson.build to build that dependency for your project.
You have couple options:
Fork project and add support for meson (optionally: make PR to official project)
Install and use it as dependency
Use conan package manager to get your dependency, you can even integrate it with meson (https://conan.io/center/libffi/3.3/?user=&channel=)
I'd like to execute GMOCK and GTEST tests inside OpenWRT.
I have x86_64 machine. My package is for x32 device.
I tried copy headers manually, but, of course, it does not work.
It is important to run tests inside the device, this is the main reason.
Is it false that the only possible way for me is to compile inside the device?(Such approach is strongly not desired)
If not, how to add gtest&gmock to the package?
You can make a custom package for gtest. Then use that as a dependency for your package. For the headers you will need to setup an InstallDev section in the gtest openwrt package makefile. Use this section to copy the header files to the staging directory where they can be used by your package for compilation.
Follow the documentation for openwrt here:
https://openwrt.org/docs/guide-developer/packages#use_packed_source_code_archive
My goal is to use a script/CMake to create a "Debug" build configuration and a "Release" build configuration that can be switched between within Code Composer Studio's UI (using the "Build Configuration -> Set Active..." option).
Currently,
A script is ran that runs CMake with desired commands (toolchain, etc). A Code Composer Studio project is generated (as described in CMakeLists.txt)
CCS project is imported into CCS
The problem is this only generates a "Debug" build configuration. Is it possible to add a command to CMakeLists.txt, or to cmake command line, or even ccs command line that allows multiple build configurations to be generated?
The only difference between the two will basically be defining NDEBUG, and possibly changing optimization level.
I had this same question...then realized I am the one who originally asked this ~4 years ago! Anyways, I found a way to do this:
Using Code Composer, create the build configuration(s) as you want them to behave. When done, copy the .cproject file to a cproject.in "template". CMake will use this template to generate an identical .cproject for any future cmake builds. Make sure to replace any hardcoded values (ex: project name) with proper cmake variables.
For me, my CMakeLists.txt called configure_file(path/to/cproject.in ${CMAKE_SOURCE_DIR}/.cproject #ONLY).
Also be sure to delete your CMakeCache and CMakeFiles if they already exist...I believe those were preventing me from seeing the resulting change.
Our project uses CMake to configure our code. We use Ninja along with a distributed build system. A number of people on our team use Eclipse CDT. We run CMake with the "Eclipse CDT4 - Ninja" generator and the result is generally pretty good.
The issues is that any time a CMake file is changed and you ask Eclipse to build the code it regenerate the eclipse project file overwriting any manual changes you've made to the project.
For example the default build command that it provides the eclipse project is /usr/bin/ninja when in fact I want to take advantage of our distributed build system and set the build command to /usr/bin/ninja -j16. It would be nice if I could have the project file that CMake generates automatically include this setting change.
The other setting I am most interested in preserving is the C/C++ Project Paths->Source. As a general rule we place our CMake build directory as a sibling to the main project directory i.e. ./project ./build. We want to include some files in the build directory in the Eclipse index to make code completion and other tools work better. The default project doesn't include the build directory in source path and thus it does not get indexed.
Is there some way to remedy these issues?
I found a solution to build command issue.
When you run cmake to generate the eclipse project include the additional argument:-DCMAKE_ECLIPSE_NINJA_ARGUMENTS=-j100. I haven't confirmed but I believe a similar command is required for eclipse make projects -DCMAKE_ECLIPSE_MAKE_ARGUMENTS=-j100.
Unfortunately this feature is poorly documented and I have not found a solution to my other issue.