Is there a way to package GHC Stage1 compiler?
I haven't built Stage2 etc. since I am only interested in cross-compiling so make install would not help here I assume.
OK, I was able to make a docker container for GHC cross compiler (which is Stage1).
The detailed steps are in the docker file.
https://registry.hub.docker.com/u/alexeyraga/ghc-docker-cross-arm/
Related
I got stuck installing "git clone https://gitlab.com/guile-git/guile-git.git". In which directory is this supposed to be cloned and installed?
Dunno if you're still looking for an answer but it doesn't seem you need this installed to install guix; the read-me of the repository says that you can install it via guix. guix is an agnostic package manager that you can install on any Linux distribution alongside the default package manager and guix is the default package manager of the GuixSD operating system (https://www.gnu.org/software/guix/).
If you're on a distro which doesn't use guix, you may not want to install guix (I've yet to find reason enough to, yet); if you use a lot of GNU tools or Guile (some Guile packages are available through guix), you may want to.
Most repositories that don't have a binary for you to run follow the build process of configure, make, and [sudo ]make install.
I cloned the repository, myself, and find that this one does, as well.
Get a terminal (if you haven't been using one, yet) and cd into the directory you cloned the repository to and then cd into the guile-git directory (cd guile-git).
If we do ls -l, we'll see that the only executable file there is the bootstrap one; I've never seen one before but doing ./bootstrap generates the configure file and sets up the make process for us. So now back in familiar territory.
Given these are Guile files, we'll probably want to install this under the same prefix as where Guile is installed so run which guile. I believe, if you install it under Ubuntu (I'm running Linux Mint), it'll install to /usr/bin/ but, if you install it manually, it'll install to /usr/local/bin/.
The latter is where mine is and that's the default prefix that configure uses so I can just do ./configure; if you wanted to install it under /usr/, run /.configure --prefix=/usr/.
This'll verify that all of the necessary libraries and programs that guile-git needs are installed and properly setup. Heads up that configure balked at me over not having the Guile module bytestructures installed (https://github.com/TaylanUB/scheme-bytestructures) so you may need to do that.
I'm not going to run through everything to get it installed but, once you can run it without any errors, run make to build it within the directory.
If you want to install it permanently on your computer with the rest of your operating system able to detect it, run make install. Since you'll likely've specified a directory under /usr, you'll have to do sudo make install so that the make process can have permissions to install under /usr/local or /usr.
Sorry if I reiterated anything you already knew; 'just didn't want to assume you knew something and result in confusion.
We have some smaller libraries we use in our bigger project quite often.
Still we compile and run the unit tests of these smaller libraries as independent CI Jobs.
Most of these libs use QMake as buildtool, not using Qt in any way. And we started to move our CI-Jobs into docker containers. Now I realized that I always have to get qt5-default (on Ubuntu 16) for qmake to work. Is this intended? This gives quite a signifacant overhead. Does anybody know a way, to use qmake on Ubuntu 16 wihtout getting the whole Qt instalation on board?
You don't actually need Qt installed for qmake to work. The reason why you need qt5-default is that most linux distributions provide both Qt5 and Qt4, which have the same binaries, for example they both have a version of qmake, which would both get installed to /usr/bin. In order to fix that problem Qt5 installs to /usr/lib/.../qt5 and Qt4 to /usr/lib/.../qt4, and the qt5-default package creates symlinks from there to /usr/bin
For Ubuntu , ... is x86_64-linux-gnu!
You can choose between:
Install only the qt5-qmake package in your docker container and create a symlink /usr/bin/qmake -> /usr/lib/.../qt5.*
Specify the full path to the qmake binary when building your software, inside your {travis, gitlab, jenkins} CI config
Add /usr/lib/.../qt5/bin to your $PATH
* The proper place for a manually created symlink would actually be /usr/local/bin because if you have the symlink in /usr/bin, installing qt5-default package would fail because the symlink qt5-default wants to create would already exist. However, you are in a docker container and can actually control whether qt5-default gets installed, and if you create the symlink in /usr/local/bin you have to make sure to add /usr/local/bin to your $PATH, which is overkill for that scenario.
It sounds very basic but I haven't found clear instructions on how to do this. I'm new on openstack. I have setted up devstack on my laptop, I have created an instance from a cirros image and now I would like this image to run a jar. I was expecting this to work in a similar way as Amazon EMR for instance, but obviously it doesn't. Any help or hints for straightforward tutorials will be appreciated.
The cirros image doesn't include Java nor does it include a facility for installing additional packages. You should boot using a full distribution of some sort (e.g., Fedora, CentOS, Ubuntu, etc), and then proceed to install Java following instruction appropriate for that distribution.
Once you have Java installed, you can install and run your jar file.
I'm interested in building an RPM package for sbt 0.12.3 that meets the Fedora packaging guidelines. In order to do this, I'll need to be able to build sbt itself against libraries that were built from source and installed via RPM packages.
Java packages in Fedora that use Ivy are able to resolve RPM-installed artifacts by disabling network resolvers and resolving all packages from /usr/share/java/[artifact].[ext] -- see here for an example.
I think I understand how to override default resolvers in sbt using a boot properties file, but this is where I run in to a problem: if I set the Ivy directory to /usr/share/java, sbt expects to be able to publish artifacts to this directory (not merely to look for existing artifacts there), which I don't want it to do (both in general and for this specific case of RPM building). If I specify file:///usr/share/java as a proxy location (following Mark's instructions below), sbt will fail (citing the absence of ivy.xml in that location).
I am able to find locally-installed dependencies by modifying project/p.sbt to point to explicit URLs (e.g. "org.jsoup" % "jsoup" % "1.7.1" from "file:///usr/share/java/jsoup.jar"), but this doesn't work for scala and the scala library (and is obviously not the right thing to do in general).
How can I build sbt against (and only against) locally-installed, RPM-managed system Scala and libraries?
For installing software, each 'platform' has its own package manager : brew, apt, pip, Bundle, etc ...
But for plain old compiled project, is there any standard for declaring dependencies in an actionable way, amenable go (brew,apt,yum..) install all of them?
As of now, I
look at whatever ./configure complains about,
brew install
add to the -L path etc...
This is quite tedious and ineffective, but I dont know any better way.
Is there such a standard mechanism I missed for plain old source code ?