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=)
Related
I checked out a gtk project inside a docker and during meson build found many dependencies are missing eg. libwayland-dev, libxrandr-dev...
Because meson fails at the first missing dependency, I had to redo this over and over to get install the entire list of dependencies that will be looked for using pkg-config. And, in projects with multiple git submodules, this becomes a lengthy process.
Wondering if I'm doing this whole thing wrong or if there is a way to get to the complete list of dependencies.
To get dependencies for your project, from build directory run:
meson introspect --dependencies
I am distributing a Java package via git for other people to use. I am currently supplying a jar file to go with the source. This way, the user only needs to clone the project once into Intellij IDEA. Projects using the package can then follow this procedure
Correct way to add external jars (lib/*.jar) to an IntelliJ IDEA project
to use the package.
This works, but distributing a jar does not feel nice security-wise. On the other hand, this discussion
IntelliJ IDEA - adding .java file to project dependencies
suggests that to use the source code, you need to copy it into your src folder.
Is there a way to distribute source code (java files) only so that if multiple projects use the same package
the package only needs to be downloaded once
the package can be kept up to date with git pull?
I would really recommend not include jar or any binaries in a Git repo and the best approach to keep these dependencies in a local Nexus repository and use maven or Gradle as your dependency management tool.
I found a working solution:
Supply an Ant build file with the package. The build file compiles classes and packages them into a jar file. The default target is building the jar, which depends on compiling the classes.
Provide users with instructions on how to set the given Ant build file as a build file in Intellij IDEA and build the default target.
Then instruct them to follow the steps in the first link above to add the jar as a dependency.
I am now reading a ROS package built on catkin_tools. It is complicated so I need to import this project into an IDE (like Clion, QT Creator, etc). Although the official doc of catkin-tools says you can't rely on CMake's IDE integration (http://catkin-tools.readthedocs.io/en/latest/migration.html?highlight=IDE), I still have some hope on this. So does anyone has such experience?
PS: I also found the author of ros_qtc_plugin claimed he has added the function of catkin_tools, but I still could not find how to do this.
Note: The following solution works for catkin build, but not for catkin_make. If you are using catkin_make, please visit:
https://stackoverflow.com/a/35143865/2422098
https://www.jetbrains.com/help/clion/2020.2/ros-setup-tutorial.html#set-build-paths
CLion configuration for catkin_tools workspaces (catkin build)
Please excuse me for digging up an old question, but I just came across this problem and found a solution for CLion and catkin_tools (i.e., when building with catkin build).
I tested the proposed solution on 20.04 with ROS Noetic and CLion 2020.2.4.
According to the docs, catkin_tools uses an individual devel workspace path for each ROS package:
https://catkin-tools.readthedocs.io/en/latest/advanced/linked_develspace.html
The devel prefix path for a package:
-DCATKIN_DEVEL_PREFIX:PATH=/home/<user-name>/catkin_ws/devel/.private/<package-name>
The build directory for a package:
/home/<user-name>/catkin_ws/build/<package-name>
To open and edit a ROS package in CLion, please follow these steps:
run catkin build in the workspace
Source /opt/ros/$ROS_DISTRO/setup.bash and your workspace setup.bash in the devel folder
After that, start CLion from the command line, so that it inherits the environment variables
In CLion's Open Project wizard, navigate to the ROS package, and select the
CMakeLists.txt. When prompted, click Open as Project
Open the Settings Window (usually Ctrl+Alt+S)
Navigate to "Build, Execution, Deployment" > "CMake"
Under "CMake options", specify the devel prefix as mentioned above, and under "Build directory", specifiy the build directory as mentioned above:
Explanation:
When configured in the aforementioned way, the generated CMake files and build files that catkin build creates are reused by CLion.
By default, when not configuring it to reuse the build files, CLion would create its own cmake-build-debug/ generation directory. I experienced the following issues with this dedicated generation/build directory:
Problems when CLion is not configured as described in the above steps:
The nodes/libraries are built twice (CLion, catkin build), which increase development time.
Libraries are built twice, but the CLion build links with ~/catkin_ws/devel .so-files and not the cmake-build-debug/ .so-files. This is confusing when working on a ROS package with at least one library, since building the library in CLion is a dead-end and the .so-output is never used.
Since executables are built twice, rosrun has an ambiguity problem as it finds two executables for the specified node. An executable selection prompt appears each time rosrun is used.
I have had success using Eclipse to work with ROS in the past. See: http://wiki.ros.org/IDEs#Creating_the_Eclipse_project_files for setup details.
If you want something that works right out of the box, you can try a free IDE called RoboWare that is specifically built for and integrates with ROS very well.
http://www.roboware.me/#/home
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.
Suppose, I have an opensource project that depends on some library, that must be patched in order to fix some issues. How do I do that? My ideas are:
Have that library sources set up as a module, keep them in my vcs. Pros: simple. Cons: some third party sources in my repo, might slow down build process, hard to find a patched place (though can be fixed in README)
Have a module, like in 1, but keep patched source files only, compile them with orignal library jar in classpath and somehow replace *.class files in library jar on build. Pros: builds faster, easy to find patched places. Cons: hard to configure, that jar hackery is non-obvious (library jar in repository and in my project assembly would be different)
Keep patched *.class files in main/resources, and replace on packaging like in 2). Pros: almost none. Cons: binaries in vcs, hard to recompile a patched class as patch compilation is not automated.
One nice solution is to create a distinct project with patched library sources, and deploy it on local/enterprise repository with -patched qualifier. But that would not fit for an opensourced project that is meant to be easily buildable by anyone who checks out its sources. Or should I just say "and also, before you build my project, please check out that stuff and run mvn install".
One nice solution is to create a distinct project with patched library sources, and deploy it on local/enterprise repository with -patched qualifier. But that would not fit for an opensourced project that is meant to be easily buildable by anyone who checks out its sources. Or should I just say "and also, before you build my project, please check out that stuff and run mvn install".
This is what I would do (and actually what I do) for both a corporate and an opensource project. Get the sources, put them under version control in a distinct project, patch them, rebuild the patched library (and include this information in the version, something like X.Y.Z-patched), deploy it to a repository (you could use SVN for this, a la Google Code1), declare the repository in your POM and update the dependency to point on your patched version.
With this approach, you can say to your users: check out my code and run mvn install and they will just get the patched version without any extra action. This is IMHO the cleanest way (not error prone, no class path order mess, no increase of the build time, etc).
1 Lots of people are deploying their code to their hosted subversion repository (how-to in this post).
One nice solution is to create a distinct project with patched library sources, and deploy it on local/enterprise repository with -patched qualifier. But that would not fit for an opensourced project that is meant to be easily buildable by anyone who checks out its sources. Or should I just say "and also, before you build my project, please check out that stuff and run mvn install".
I'd agree with this and Pascal's answer. Some additional notes:
you may use dependency:unpack on the original artifact and then combine that with your compiled classes if you don't want to rebuild the whole dependant project
in either case, your pom.xml will need to correctly represent the dependencies of that library
you can still integrate this as part of your project's build to avoid the 'deploy to a repository' step
make sure you honour the constraints of the project's license when doing all this!