We have Yocto recipe which we deliver to our customer. Customers use different versions of yocto and Linux Kernel.
Is it possible to deliver one recipe for the old and new syntax?
Or we should always deliver 2 version of recipes?
Related
I have a fairly popular open source project that has a minimum cmake version set that is fairly old (~Oct 2013).
cmake_minimum_required(VERSION 2.8.12)
This is great for supporting a wide variety of users, but it makes adding new things to our cmake builds challenging, since we cannot use any of the new features in later cmake versions. This leads to complicated cmake files and more maintenance burden to emulate future improvements made to cmake.
I would like to support two CMakeLists.txt files for the project that have different minimum versions, one legacy one at the 2.8.12 version, and another more modern one at a later 3.x version. Is there any canonical way to do this? It doesn't look like there is a way to support multiple CMakeFiles.txt at the root of the project.
The naive way is to just rename the legacy file CMakeFiles_Legacy.txt and have users that depend on the older cmakes manually switch out the CMakeFiles.txt on their own.
tl;dr: Just don't support old versions.
CMake is absurdly easy to upgrade. Literally every halfway-modern development platform natively packages at least CMake 3.16+, but Windows and macOS are both way ahead of the curve with constant updates to the included version.
Visual Studio receives periodic updates and 2022 includes CMake 3.21. The version on Chocolatey is always up to date.
On macOS the Homebrew version is always up to date.
On Debian derivatives, Kitware provides an official APT repo that is always up to date. There is also a Snap package that is always up to date.
On most other Linux distros, one can use the official binaries directly from Kitware without sudo access at all. They have x86_64 and aarch64 binaries. The binaries are statically linked and require only libc6 as a dependency. Glibc has been ABI-stable since 1997. It will work on your system. But even if it doesn't, building a recent CMake version isn't difficult anyway. Your users maintaining such archaic systems shouldn't be your liability.
(aside: I wrote an entire blog post on this... https://alexreinking.com/blog/how-to-use-cmake-without-the-agonizing-pain-part-1.html)
my company deployed a conan package at their artifactory server. There are several versions of this package available for different configurations. Let's say there are two versions, one for Ubuntu and one for Debian. The urls of these versions are looking like this:
https://artifactory.<my-company>/artifactory/<the-project-depending-on-the-conan-package>/_/<name-of-the-package>/<version-number-of-the-package>/_/0/package/<THE-HASH-FOR-UBUNTU-VERSION>/0/conan_package.tgz
https://artifactory.<my-company>/artifactory/<the-project-depending-on-the-conan-package>/_/<name-of-the-package>/<version-number-of-the-package>/_/0/package/<THE-HASH-FOR-DEBIAN-VERSION>/0/conan_package.tgz
When we build a project, which depends on this package, we need to download the fitting version of it (Ubuntu or Debian). Unfortunately, these downloads need to happen during the build (we use cmake).
Now my question: As you can see, the urls contain the hash of the package versions. But when I build the project, how do I now which hash is for the Ubuntu or the Debian version? Obviously I need to distinguish between the two hashes to download the fitting package-version.
Note: Please assume that my conan-cache is empty.
I hope you guys can help my and please correct my if I there are any missunderstandings (I am new to cmake, conan and artifactory).
Trying to move the Dmgrs and Nodes to new machines with different OS.
The WAS install paths and profile locations are different on source and target servers
Both source and target machines are on 8.5.5.17 versions
Different OS for source (intel) & target (power)
I wanted to check if we can use wasPreUpgrade and WASPostUpgrade scripts for this kind of migration too and follow the steps listed on this
https://www.ibm.com/docs/en/was-zos/8.5.5?topic=SS7K4U_8.5.5/com.ibm.websphere.migration.nd.doc/ae/tmig_migrate_remote_commandline.html
OR
can we use the approach to be able to use different install locations
do a new install, create new profiles and then use
importWASConfig.py script and exportWASConfig.py script from old envt to new envt
No, those scripts require you to upgrade to a newer major version of WebSphere.
Someone has figured out a procedure to move profiles over, maybe this achieves what you need to do: http://akhilesh-humbe.blogspot.com/2013/06/moving-profile-to-new-host-in-websphere.html
Otherwise you will have to request support from the vendor to help you figure out how to move the profiles.
From a set of CMakeLists.txt files, how can I determine an appropriate version number for cmake_minimum_required()? Is there a better way than being familiar with the history of CMake features and using trial and error?
CMake has per-version documentation on its website. Using it, you may check that all features you use in your project are supported by a specific CMake version.
Features include command names, command options and their possible values, names of modules shipped with CMake.
Usually project does not need precise minimum CMake version. You may take reasonable version, which is accessible for users, and check whether this version supports all features you use.
I have a pro version and a lite version of the app that have nearly identical codebases. The difference being that the lite version has ads in various view controllers as well as in app purchases. I have each version on its own branch in Git with the lite version being the master branch currently.
I have localized the pro version, switched all strings to NSLocalized string, added localization files etc. I am wondering what the best way to merge these changes into the lite version without overwriting the differences between the two. When I open a "merge into..." session in Xcode, it automatically would overwrite the differences.
Is there a way to skip a block of code in a merge?
There may not be a solution for this but before I do it manually, I just wanted to check.
It's not a git problem but a project structure problem. You should never have tried to misuse git branches for this purpose to start with. Instead, you should have used Xcode's project / workspace facilities (or a framework) to organize the code itself so that it could be shared between two targets.