Is it possible to manage multiple versions of Perl 6 using rakudobrew?
I tried:
$ rakudobrew build moar
but this just overwrote my previous version, which was not what I intended to do. My previous version was 2017.04.3, when I now type
$ perl6 --version
This is Rakudo version 2017.07-117-g5f68c7752 built on MoarVM version 2017.07-266-ged84a632
implementing Perl 6.c.
I am looking for something similar to perlbrew install and perlbrew switch which I use to switch between different version of Perl 5.
moar is a backend. To get a specific Rakduo version, you have to specify it as well:
rakudobrew build moar 2017.07
rakudobrew build moar 2017.04.3
After doing this, you can choose which one to use:
rakudobrew switch moar-2017.04.3
If you are interested, run rakudobrew list-available to get a list of all Rakudo versions and backends that are available.
A note to most users: Unless you really have a need for the "bleeding edge" version of Rakudo, I'd recommend the relatively easier-to-install and "maintenance-free" Rakudo Star distribution. It is released about once every three months, so it's not that far behind the "bleeding edge" anyway.
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)
I just installed msys2 and mingw64, with their development packages. I really need perl-Gtk3. Perl is msys2 and compiled with gcc-4.9.x, Gtk and friends are mingw and compiled with gcc-5.
Perl complains "Glib.c: loadable library and perl binaries are mismatched (got handshake key 0xde00080, needed 0xdd80080)" when building Glib. Should this work?
Thanks.
PS ... mingw-w64-x86_64-perl is simply unable to compile. And yes, I'm careful to use a mingw shell vs an msys shell.
Are you still having this problem? I have been able to build a Perl dev environment in MinGW64, current as of this time.
I have been able to build Perl Gtk2 / Gtk3 applications in that environment and the GUIs work. (Both Gtk2 and Gtk3 based). These applications are used in a production environment with several thousand desktop users. The application runs on OSX, Windows, and Linux, and can be packed into a binary for release as an "executable" for those operating systems. The details here are for the Windows version.
I do this by either installing the requisite system packages first with pacman, then as necessary rebuilding whatever system library packages that I may have modified, from source, using makepkg-mingw.
Then I build the requisite Perl modules using the CPAN shell, and the "look" command.
I use pkg-config to detect what library and header files are needed.
I then build (at minimum), the Perl Glib, Pango, Cairo, Gtk2, and Gtk3 modules using the perl Makefile.PL command.
The LIBS and INC options need to be added to that command to create a Makefile that includes the correct header files, and links to the correct libraries. The EXTRALIBS and LDLOADLIBS sections of the Makefile needs be correct.
Also ExtUtils::MM_Win32.pm ExtUtils::Liblist::Kid.pm needed to be edited due to the different archname reported by the MinGW64 perl.
I am only giving a general answer, because I was thinking offing a YouTube video on this. If this is a desired topic I will.
According to the documentations, when deploying a project to scrapyd, I can use the git commit hash as the version, by doing this:
$ scrapyd-deploy default -p myproject --version GIT
The documentation also says that scrapyd can keep multiple versions of the same project, but will only run spiders from the latest version.
In that case, how does scrapyd determine which version is the 'latest' to use?
I hope it doesn't sort the git commit hashes lexicographically and use that order.
As stated in their docs:
Scrapyd will use the greatest version when not specified, the version must be comparable according to distutils.version.LooseVersion.
This means that using GIT as version doesn't make much sense, which is a rather big issue
I'm trying to build an embedded simple web browser for an embedded device and I've decided to use WebKit / WebKitGTK+. However, our device uses a Linux environment somewhat based on CentOS 5.8. I haven't been able to find any RPMS or mention of support for WebKit / WebKitGTK+ for CentOS 5.8 while doing several web searches.
Does anybody know if it's possible to build an older version of WebKitGTK+ such as 1.2.6-2.el6_0 which works well on CentOS 6.3? Are any RPMS available for CentOS 5.8?
The goal here is to be able to run a relatively current, at least 1.2.6 version of WebKitGTk on CentOS 5.8
Note: I was able to sort everything out. Just took a long time compiling all of the dependencies in the correct order with the correct options. I was able to get WebKitGTK 1.6.0 running on Centos 5.8.
You shouldn't have any problems building an old version of webkit if you can install the older versions of libraries that it requires.
If you have older or newer versions of GTK+ etc installed than the old version of webkit requires it may need quite a bit of porting to compile.
I'm not aware of any RPMs that meet your requirements
Depending on the compilation options you should be able to compile the dependencies in an isolated directory. With each library you typically use the --prefix option to specify the destination. Then when compiling something that depends on that library, you typically have an option to specify where to look for that library - something like --with-libraryname=/path/to/library. You want to check ./configure --help of each thing you're compiling to get the correct options.
It'll be quite a bit of work, but you should be able to compile everything you need into an isolated directory without replacing anything on the system. I would highly recommend you avoid doing this in root to ensure you have the right options.
Suppose I've written a Haskell package that I'd like to release to Hackage.
Suppose I've written automated tests for it, so I know it works on my machine, with the version of GHC I have installed, and the versions of other packages it depends on that I have installed.
Is there an automated way of running my package's tests using other versions of packages it depends on, and other versions of GHC (and versions of Hugs, etc)?
The objective is not only to check that it works with the prerequisites I think it should work with, but also to confirm it doesn't work with versions I expect it not to work with.
I think for now your best bet is cabal-dev or capri and some homegrown scripts.
Use cabal configure --preference=DEPENDENCY, as described by cabal configure --help. I don't know, how it work, maybe just try it out. For instance, to test with the old base package, try
cabal configure "--preference=base==3.0.0"
You may put the combinations of dependecies you want to test into some shell script, however you like.