From the site https://wiki.eclipse.org/Tycho/Target_Platform, I infer the following:
If the 'repositories' section contains a p2 repository, everything inside that repository is automatically considered part of the target platform as far as Tycho is concerned.
If a target definition file is referenced, everything inside that target definition file is considered part of the target platform as far as tycho is concerned.
Let's say that I have a repository under 'repositories' that points to http://download.eclipse.org/releases/indigo like in the example. Furthermore, I declare a target definition file that points to http://download.eclipse.org/releases/helios instead.
In Eclipse, developers then use the target definition file as the target platform. For dependencies in individual plug-in projects no version is defined, since the versions of the bundles are already defined by the target definition file.
The question: Will Tycho build using Indigo or Helios versions?
The target platform will contain both content from Indigo and Helios. Quoting the Target Platform wiki page:
In case multiple target platform configuration approaches are combined, the target platform contains the union of the content defined through each approach.
So for the dependency resolution, Tycho could either use Indigo bundles, or Helios bundles, or a mixture of these.
The resolution is based on the p2 planner which finds a valid solution to satisfy the requirements. In case there are multiple solutions, the p2 planner has a preference towards later bundle versions and a small set of transitive dependencies. These preferences often contradict each other, e.g. when a later version of a bundle has a larger set of transitive dependencies. So in general it is hard to predict which versions are picked in such a case.
So, if you need to know what your bundles are compiled against, use a target platform which appropriately restricts the available versions.
Related
I am learning CMake, and I feel hard to understand when I should use find_package.
For separate compilation, we need to let the compiler knows where to find the header file, and this could be done by target_include_directories. For linking, we need to let the linker knows where the implementation is, and this could be done by target_link_libraries. It seems like that is all we need to do to compile a project. Could anyone explain why and when we should use find_package?
If a package you intend allows for the use of find_package, you should use it. If a package comes with a working configuration script, it'll encourage you to use the library the way it's intended to be used likely come with a simple way to add include directories and dependencies required.
When is it possible to use find_package?
There needs to be either a configuration script (<PackageName>Config.cmake or packagename-config.cmake) that gets installed with the package or find script (Find<PackageName>.cmake). The latter one in some cases even comes with the cmake installation instead of the package installed, see CMake find modules.
Should you create missing scripts yourself?
There are several benefits in creating a package configuration script yourself, even if a package doesn't come with a existing configuration or find script:
The scripts separate the information about libraries from the logic used to create your own target. The use of the 2 commands find_package and target_link_libraries is concise and any logic you may need to collect and apply information like dependencies, include directories, minimal versions of the C++ standard to use, ect. would probably take up much more space in your CMakeLists.txt files thus making it harder to understand.
If makes library used easy to replace. Basically all it takes to go with a different version of the same package would be to modify CMAKE_PREFIX_PATH, CMAKE_MODULE_PATH or package-specific <PackageName>_ROOT variables. If you ever want to try out different versions of the same library, this is incredibly useful.
The logic is reuseable. If you need to use the same functionality in a different project, it takes little effort to reuse the same logic. Even if a library is only used within a single project, but in multiple places, the use of find_package can help keeping the logic for "importing" a lib close to its use (see also the first bullet point).
There can be multiple versions of the same library with automatic selection of applicable ones. Note that this requires the use of a version file, but this file allows you to specify, if a version of the package is suitable for the current project. This allows for the checking the target architecture, ect. This is helpful when cross compiling or when providing both 32 and 64 bit versions of a library on Windows: If a version file indicates a mismatch the search for a suitable version simply continues with different paths instead of failing fatally when considering the first mismatch.
You will probably find CMake's guide on using dependencies helpful. It describes find_package and alternatives, and when each one is relevant / useful. Here's an excerpt from the section on find_package (italics added):
A package needed by the project may already be built and available at some location on the user's system. That package might have also been built by CMake, or it could have used a different build system entirely. It might even just be a collection of files that didn't need to be built at all. CMake provides the find_package() command for these scenarios. It searches well-known locations, along with additional hints and paths provided by the project or user. It also supports package components and packages being optional. Result variables are provided to allow the project to customize its own behavior according to whether the package or specific components were found.
find_package requires that the package provide CMake support in the form of specific files that describe the package's contents to CMake. Some library authors provide this support (the most desirable scenario for you, the package consumer), some don't but are prominent enough that CMake itself comes with such files for those packages, or in the worst case, there is no CMake support at all, in which case you can either do something to get the either of the previous good outcomes, or perform some kludges to get the job done (ie. define the targets yourself in your project's CMake config).
It's a .jar available in various versions at Maven Repo.
But what category is it? It is published by org.codehaus.groovy, the same outfit that I get my groovy-all dependency from. I also find that import groovy.sql doesn't work in a script unless I specifically include this dependency. So it would appear not to be part of the core language.
Outside a Gradle context I find that I have to manually put the .jar file under ~/.groovy/lib in order to use it. If I put the wrong version (e.g. 2.5.9 for 3.0.2) under ~/.groovy/lib the script won't run... even if I'm not using groovy.sql at all!
Is this a "dependency"? It seems a typically powerful and hassle-free Groovy way of manipulating databases. Are there any other powerful add-on (non-core) Groovy .jar file modules like this, which have to be manually placed under ~/.groovy/lib, that I should know about?
groovy consists of subprojects:
https://github.com/apache/groovy/tree/master/subprojects
and groovy-sql one of the subprojects
all subprojects are published in maven as separate libraries
prior to version 2.5 there was groovy-all-XX.jar that includes all other groovy libraries
https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.4.19/
however starting from v 2.5 groovy-all represented by groovy-all-XX.pom that depends on all other groovy libraries
https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.5.0/
so, to include all groovy features you have to specify groovy-all in your maven/gradle/... dependency
and finally useful site to dig dependencies:
https://mvnrepository.com/artifact/org.codehaus.groovy/groovy-all/3.0.2
I have a GitHub repo that is an Objective-C project that defines multiple targets (one per each targeted OS: macOS, iOS, tvOS, etc.). These targets share most of the source code files of the project.
I am trying to add SPM support to the project and in the Package.swift file I define matching targets with source path referring to the same folder containing those source code files shared across the targets.
When I add this SPM-"enabled" project/package to a test project that is trying to use it as a dependency via SPM, I get an error saying that the second target in the dependency package having overlapping sources with another target (the first one that uses the same shared source code files).
Any ideas about how to fix the problem? I would assume my multi-target configuration over the shared source code files is not that uniqueue...
I finally figured out what was the problem and what should be a solution to it.
My mistake was to think of SPM targets the same way Xcode thinks of them. In reality, SPM targets are essentially named folder containing source code files that need to be built to produce a product or products. They do not assume a definition of a recipe regarding how to build (the way Xcode targets do). However, a codebase that depends on a given SPM package does apply its Xcode targets to build itself and the dependency (prior to building its own codebase). The SPM targets are completely agnostic to the targeted device.
Hence, when I tried to map all my Xcode targets as similar SPM targets (at the same time referring to the same source code files from multiple SPM targets) it was wrong from the SPM point of view.
The correct solution anded up to be a definition of a single SPM target over a single codebase location (path) and everything went well from there.
Here is a good video that explains the SPM concepts well and that subsequently led me towards the working solution:
Creating Swift Packages
We aim at using Tycho+Eclipse PDE to build OSGi bundles in a distributed team.
So far artifacts are built and deployed to a Nexus OSS repository. This has been
augmented with p2 support, "artifacts.xml" and "content.xml" are generated
(or supplied by Tycho) and correctly resolved by Tycho and the p2 Browser.
The missing link is to add the resultant p2 bundle repository to the target platform
definition used by PDE. The PDE target editor apparently only supports features
or "categorized" plugins, no plain bundles.
Tycho's repository plugin and feature-packaging of bundles independently developed by
different partners appears too cumbersome to synchronize. We'd like to adhere to simple
Maven/OBR-like sharing of bundles via a single repository.
Is there a way to enhance the bundle's or repository's p2 metadata in terms of a
generic category as suggested in this blog, e.g. either via the "tycho-p2-publisher:publish-categories" goal or by configuring/extending the "Nexus p2 Repository Plugin" to make them accessible to the PDE UI ?
This questions seems related to this question, with a hint that support for the "iu" syntax is not implemented yet.
Maybe you should try another target editor. There exists a alternative TPD editor/generator from Mikaël Barbero with some useful features:
autocomplition
version management
mergeable structure
...
Is there a way to tell Ivy to prefer the latest version of a particular library among the transitive dependencies, without turning the transitive dependency into a direct dependency?
After retrieving the artifacts required for a build I end up with two versions of the same library, both as transitive dependencies. I've run a report so I know where the libraries are coming from but I'd prefer not to end up with references to transitive libraries in my ivy.xml file.
The Ivy manual states "If no specific conflict manager is defined, a default conflict manager is used for all modules. The current default conflict manager is the 'latest-revision' conflict manager". Apparently that doesn't apply to transitive dependencies.
Is there a way achieve what I want without directly referencing transitive libraries?
Transitive dependencies are dependencies of your dependencies, so conflicts can occur when one or more versions of the same library are referenced. This is where the conflict manager functionality kicks in. By default, ivy will choose the most recent version, working on the assumption that most libraries are backwardly compatible. If you review the report generated by the report task you'll see the other version(s) marked as "evicted".
Your question appears to put forward an alternative mode of operation? Perhaps an example would help.