is there a portable edition of perl 6 ?
or its possible to compile it and install some modules zip all to one directory , and then unzip on different machines having the same OS ?
If both computers have the same filesystem layout -- maybe. At the very least all absolute paths to these items would need to be identical or else you'd have bad precompiled files everywhere.
Of course this is not a very practical solution ( how many computers do you have with the same home directory ), but for instance you could ( and indeed we used to ): build rakudo inside of travis-ci, push the entire folder to a private repo, and then could pull that repo down from other travis instances to get an already-built version of the very latest rakudo release.
May be you can run Perl 6 on Android: https://github.com/termux/termux-packages/issues/1324, but current there is no package for Perl 6 on Termux.
Some time in 2019 Rakudo gained the ability to be relocated. Since the 2019.11 release pre-compiled, relocatable binaries are provided for every release. They can be downloaded from rakudo.org.
So you can download such an archive, extract it to some folder, install modules with the included package manager zef, bundle it up with your own code, zip it and it will work on any computer (given it's the same architecture and OS), in any folder.
Related
I want to investigate a new application for JPEG 2000 encoding and decoding. I downloaded openjpeg-master and managed to cobble together the ability to cmake the files. After a bunch of grinding, this resulted in the following output:
"Build files have been written to: C: openjpeg-master/build
\build> "
Any "normal" Unix installations have a multi-step installation like this:
"UNIX/LINUX - MacOS (terminal) - WINDOWS (cygwin, MinGW)
To build the library, type from source tree directory:
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make
Binaries are then located in the 'bin' directory.
To install the library, type with root privileges:
make install
make clean
To build the html documentation, you need doxygen to be installed on your system. It will create an "html" directory in TOP_LEVEL/build/doc)
make doc"
But the Windows 10 equivalent is unclear, to put the most charitable spin on it. You can find it here: "https://github.com/uclouvain/openjpeg/blob/master/INSTALL.md"
Some questions arise:
is there a better starting place for installing JPEG 2000 that actually shows me how to install it and run the tests?
if not, how do I get from the build files to installing the libraries and making the test programs?
Is there more information I can dig out that would help to answer these questions?
Since I'm allergic to Visual Studio, I overlooked a nice tutorial specifying how to install something as complex as openjpeg by direct clone from github. However, in desperation, I found it and it worked. It is Visual Studio Community 2019 Version 16.8.3. I needed only to use -DTHIRDPARTY to get the third party libraries installed. There is a drop-down menu to build and install OPENJPEG. All I need to do now is figure out how to compile and run the utilities that invoke the installed libraries ...
actually, the complete line to add was -DBUILD_THIRDPARTY:bool=true.
Somewhere in my frantic random search for a way forward, I remember seeing the thought that to make the tests work, I merely need to find files like *.vsproj and run them a separate VS solutions. Some random guesswwork with .vdproj files in src/bin/... hasn't produced anything good. Is there not a document somewhere showing how to run the tests?
Is there a way to backup the previous installed version of a .deb package generated by cpack?
I have a project that i need to deploy manually on multiple equipments in a live production site. To minimize error and time spent deploying, i would like to use cpack and a .deb generator to create a package.
But i also want to keep the previous installed version, and config files for fast roll-back.
I have already have a package with can be successfully installed with it's configuration files. Contained in a folder with the version as a name. But when I install the new version it automatically removes the older version. Is there a way to stop the installer from doing this?
I've solved my problem by moving away from the .deb package and I'm instead using the .stgz package with a custom script.
To create this script have a cmake folder in your project for cmake scripts. This is done by setting following line into your cmake file.
list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/Resources/CMake")
Copy a CPack.STGZ_Header.sh.in file into this directory. Normally you will find one in /usr/share/cmake-3.10/Modules/.
Edit this file at will to reflect it what you want to do. Make sure to leave the 3 line that really unpack your package untouched.
I am trying to build a .deb package for an application my company (and me) have been developing.
I'm trying to create a 64bit package on my 32bit ubuntu (12.04 LTS) using dpkg-buildpackage and I get the following warnings/errors:
dpkg-shlibdeps: warning/error: couldn't find library X needed by Y.so (ELF format: 'elf64-x86-64'; RPATH: 'some/path/that/does/not/exist')
When X is one of our compiled shared libraries, we get a warning. When it's a system library (like libgcc_s.so.1 and libstdc++.so.6) we get an error.
Why is the RPATH refers to a path that does not exist?
By the way, when I make a 32bit package (on our files that were compiled for 32bit of course) it only shows warnings (only about our proprietary .so files) but creates the .deb file.
If I could, I would have posted my debian folder content but I cant take files out of our network. I can type the relevant parts if its needed.
You need to install the 64-bits version of the library with apt-get (actually anything do, but this is the most easy):
sudo apt-get install libyouneed-dev:amd64
The trick here is the :amd64, which tells the package manager to install the 64-bit version of that package. The same applies for 32-bits libraries in 64-bit systems. It's called multiarch.
The package is looking at that path because that is where the libraries of 64-bits (or 32-bits) gets stored, but since you don't have it installed the path do not exist.
Install an amd64 chroot environment and build your package in there. This way you avoid the various multi-arch pitfalls, with the added benefit of having a clean, reproducible build.
There is a tool that makes this very easy: mk-sbuild.
You need to install ubuntu-dev-tools and sbuild.
Then, run mk-sbuild --arch=amd64 precise, which will setup the build environment for you.
Add yourself to the sbuild group: adduser <your user name> sbuild
Log out and log back in so your group membership will be reflected.
You can then build your package in the chroot:
sbuild -d precise --arch=amd64 name_of_package.dsc
This assumes you've already build the source package with debuild -S or similar.
I want to include the GNU Scientific Library (GSL) in my Cocoa app so that the user needs not installing it locally first. Like most GNU packages, it's the standard configure / make / make install routine. But this won't work:
./configure --prefix ~/libgsl
make
make install
Since the prefix is local to my computer. And neither is this:
./configure --prefix (path to build folder)/libgsl
make
make install
What I want is essentially the GSL being contained entirely in my application, and I can call its functions without the users downloading anything else.
I'm rather new to Xcode 4 and the build system for Clang/GCC, having coming over from .NET. Any help is much appreciated.
Assuming there is not a framework-style build of the library, the way this is typically done when bundling with 3rd party libraries is to build the package as normal, install it in /usr/local, and configure your project to include and link from there. Building is the easy part though.
The tricky part is bundling up the .app correctly. You need to add a custom build stage (after the others) which first copies all the dependent .dylib files into your app bundle's Frameworks folder (using the environment variables to help; see Xcode docs). Then you need to use install_name_tool to get the app binary to look in the framework dir (as the embedded soname still thinks it is in /usr/local). This part is very fiddly and not well documented.
I've just extracted this from a working project where I use GSL. Just add this as an extra build phase in your XCode project as a Custom Script:
# Framework folder for Example.app
FRAMEWORKS_DIR=${TARGET_BUILD_DIR}/Example.app/Contents/Frameworks
# Create path if it doesn't exsit
mkdir -p ${FRAMEWORKS_DIR}
# Find the original linked path for libgsl
GSLLIB=`otool -L ${TARGET_BUILD_DIR}/Example.app/Contents/MacOS/Example | grep libgsl | cut -d" " -f1`
GSLPATH=`dirname $GSLLIB`
# Copy the dylibs into your app
cp /usr/local/lib/lib{gsl,gslcblas}.0.dylib ${FRAMEWORKS_DIR}
# Update embedded paths
install_name_tool \
-change ${GSLPATH}/libgsl.0.dylib \
#executable_path/../Frameworks/libgsl.0.dylib \
${TARGET_BUILD_DIR}/Example.app/Contents/MacOS/Example
This should work with a simple substitution of your app name.
This is basically the same as what you need to do to build a standalone Qt app, so the docs here are very relevant:
Deploying Qt on the Mac
It is worth reading up on bundles, frameworks and packaging. For example:
Mac OS X Framework Reference
This post is also relevant:
How do I link libraries in Xcode 4?
Note that GSL is published under the GPL, so your app would need to be similarly published in order to respect the license. Shipping the source is necessary, but not sufficient for compliance.
I just built Rakudo and Parrot so that I could play with it and get started on learning Perl 6. I downloaded the Perl 6 book and happily typed in the first demo program (the tennis tournament example).
When I try to run the program, I get an error:
Divide by zero
current instr.: '' pc -1 ((unknown file):-1)
I have my perl6 binary in the build directory. I added a scripts directory under the rakudo build directory:
rakudo
|- perl6
\- scripts
|- perlbook_02.01
\- scores
If I try to run even a simple hello world script from my scripts directory I get the same error:
#!/home/daotoad/rakudo/perl6
use v6;
say "Hello nurse!";
However if I run it from the rakudo directory it works.
It sounds like there are some environment variables I need to set, but I am at a lost as to what the are and what values to give them.
Any thoughts?
Update:
I'd rather not install rakudo at this point, I'd rather just run things from the build directory. This will allow me to keep my changes to my system minimal as I try out different Perl6 builds (Rakudo * is out very soon).
The README file encouraged me to think that this was possible:
$ cd rakudo
$ perl Configure.pl --gen-parrot
$ make
This will create a "perl6" or "perl6.exe" executable in the
current (rakudo) directory. Programs can then be run from
the build directory using a command like:
$ ./perl6 hello.pl
Upon rereading, I found a reference to the fact that it is necessary to install rakudo before running scripts outside the build directory:
Once built, Rakudo's make install target will install Rakudo
and its libraries into the Parrot installation that was used to
create it. Until this step is performed, the "perl6" executable
created by make above can only be reliably run from the root of
Rakudo's build directory. After make install is performed,
the installed executable can be run from any directory (as long as
the Parrot installation that was used to create it remains intact).
So it looks like I need to install rakudo to play with Perl 6.
The next question is, where rakudo be installed? README says into the Parrot install used to build.
I used the --gen-parrot option in my build, which looks like it installs into rakudo/parrot-install. So rakudo will be installed into my rakudo\parrot-install?
Reading the Makefile, supports this conclusion. I ran make install, and it did install into parrot_install.
This part of the build/install process is unclear for a newbie to Perl6. I'll see if I can up with a documentation patch to clarify things.
Off the top of my head:
Emphasize running make install before running scripts outside of build. This requirement is currently burried in the middle of a paragraph and can be easily missed by someone skimming the docs (me).
Explicitly state that with --gen-parrot will install perl6 into the parrot_install directory.
Did you run make install in Rakudo?
It's necessary to do it to be able to use Rakudo outside its build directory (and that's why both the README and http://rakudo.org/how-to-get-rakudo tell you to do it.
Don't worry, the default install location is local (in parrot_install/bin/perl inside your rakudo directory).
In response to your update I've now updated the README:
http://github.com/rakudo/rakudo/commit/261eb2ae08fee75a0a0e3935ef64c516e8bc2b98
I hope you find that clearer than before. If you still see room for improvement, please consider submitting a patch to rakudobug#perl.org.